You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Add the focused regression below in package internal/execir.
Run GOCACHE=/tmp/terfyn-go-cache go test ./internal/execir -run TestLargeIntegersRemainDistinct -count=1.
Observe that the distinct int64 values compare equal.
Minimal project / .agent source (if applicable)
funcTestLargeIntegersRemainDistinct(t*testing.T) {
constaint64=9007199254740992constbint64=9007199254740993ifvaluesEqual(a, b) {
t.Fatalf("valuesEqual(%d, %d) = true", a, b)
}
less, err:=compareOrdered("<", a, b)
iferr!=nil { t.Fatal(err) }
if!less {
t.Fatalf("compareOrdered(<, %d, %d) = false", a, b)
}
}
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
execir: compare integers exactly above 2^53 (#573)