fix(workflow): allow cross-type numeric comparison in selector operator WillAccept

[nankingjing]

Problem

The WillAccept method in backend/domain/workflow/internal/nodes/selector/operator.go has an overly restrictive type check for OperatorEqual and OperatorNotEqual. The condition at line 60:

if leftT.Kind() == reflect.Bool || leftT.Kind() != reflect.String {

This enforces strict type equality (leftT == rightT) for all non-string types, including int64 and float64. However, the runtime evaluation in Clause.Resolve() (clause.go) uses alignNumberTypes() to transparently handle int64-vs-float64 comparisons. The subsequent check at lines 66-70 also explicitly validates cross-numeric operands.

Impact: Comparing int64 with float64 (e.g., 1 == 1.0) is rejected by WillAccept with "left operant and right operant must be same type", even though the runtime correctly handles it. This prevents valid selector conditions from being validated.

Fix

Change line 60 to only enforce strict type equality for booleans:

if leftT.Kind() == reflect.Bool {

This is correct because:

• Bool: must match bool (strict equality)
• String: flexible, non-string types can be compared via string conversion
• Int64/Float64: cross-type check is already handled by the dedicated numeric validation at lines 66-70, which ensures rightT is int64 or float64

Verification

• Traced all code paths through WillAccept (operator.go) and Resolve (clause.go) to confirm the fix does not introduce any regressions
• Existing operator_test.go tests all continue to pass logically (no test case covers int64-vs-float64, confirming the gap)
• Single-line change, no new imports or API surface changes
• Verified by reading; not compiled/executed

Signed-off-by: nankingjing nankingjing@users.noreply.github.com

Generated with Claude Code

[nankingjing]

Review: fix-selector-numeric-accept (#2716)

Verdict: LGTM

The original condition leftT.Kind() == reflect.Bool || leftT.Kind() != reflect.String was effectively saying "for any non-string type, require exact type match between left and right." This incorrectly blocked int64==float64 and float64==int64 comparisons.

By removing || leftT.Kind() != reflect.String, the strict type check now only applies to Bool (which cannot be meaningfully compared across types). Numeric types pass through to the downstream validation on line 66 which correctly ensures rightT is also int64 or float64.

Edge case trace after the fix:

• int64==float64: passes line 56 (both accepted), skips line 60 (not Bool), passes line 66 (both numeric). Correct.
• int64==string: passes line 56, skips line 60, fails line 66 (string not numeric). Correctly rejected.
• bool==string: passes line 56, enters line 60 (Bool), fails type mismatch. Correctly rejected.

Nit: No test included. A table-driven test for WillAccept would strengthen this, but the fix itself is correct and minimal. Merge-ready.