Skip to content

execir numeric comparisons lose integer precision above 2^53 #560

Closed

Description

@leo-aa88

What happened

Execution-IR numeric comparisons convert every int/int64 operand to float64 before equality or ordering. Distinct integers above 2^53 therefore collapse to the same floating-point value. For example, 9007199254740992 == 9007199254740993 evaluates true, and < evaluates false.

This can select the wrong if arm, stop or continue a bounded loop incorrectly, or produce the wrong retry outcome for valid integer-valued workflow data/literals. Integer-vs-integer comparisons must remain exact; mixed integer/float comparisons need a range-aware implementation that does not round the integer before deciding equality/order.

Steps to reproduce

  1. Add the focused regression below in package internal/execir.
  2. Run GOCACHE=/tmp/terfyn-go-cache go test ./internal/execir -run TestLargeIntegersRemainDistinct -count=1.
  3. Observe that the distinct int64 values compare equal.

Minimal project / .agent source (if applicable)

func TestLargeIntegersRemainDistinct(t *testing.T) {
	const a int64 = 9007199254740992
	const b int64 = 9007199254740993
	if valuesEqual(a, b) {
		t.Fatalf("valuesEqual(%d, %d) = true", a, b)
	}
	less, err := compareOrdered("<", a, b)
	if err != nil { t.Fatal(err) }
	if !less {
		t.Fatalf("compareOrdered(<, %d, %d) = false", a, b)
	}
}

Command output

--- FAIL: TestLargeIntegersRemainDistinct (0.00s)
    bughunt_temp_test.go:9: valuesEqual(9007199254740992, 9007199254740993) = true
FAIL

Terfyn version

d506e9f1095a625b2df70c160454cba1ed6e3709

Operating system

Linux

Go version (if built from source)

go version go1.25.0 linux/amd64

Anything else

The loss is in internal/execir/eval.go: valuesEqual and compareOrdered both delegate to toFloat. Add tests around ±2^53, math.MaxInt64, integer/float mixtures, negative values, and ordinary fractional floats. Branch-level coverage should prove the correct arm executes.

Before submitting

  • I searched existing issues and this is not a duplicate.
  • I can reproduce this on the latest release or main.

Activity

  1. added a commit that references this issue on Sep 29, 2026
    2bf4a8c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workinggood first issueGood for newcomershelp wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions