engine: coerce CEL results to canonical native values (SPEC §5.1)#41
Merged
Conversation
celpy returns its own wrapper types (IntType/DoubleType/BoolType/StringType/ MapType/ListType) which subclass their natives, so they serialized and compared fine but leaked a guard-language implementation detail through the public boundary (resolved_esvs, snapshots, --json, observer): 'assign active = active + 1' yielded celpy.celtypes.IntType instead of int. Normalize every CEL result to native Python at the single choke point (cel.evaluate, via _from_cel), covering all value kinds and nested containers. Add unit tests asserting native types for every esv kind and that snapshots hold no celpy types. Closes #40.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #40. Implements the boundary rule from fruwehq/harel#32 (SPEC §5.1, merged via harel#33).
Problem
CEL-produced values surfaced celpy wrapper types through the public boundary:
assign active = active + 1maderesolved_esvs()["active"]acelpy.celtypes.IntType, while a host-seededintstayed native. Harmless to conformance/--json(the wrappers subclass their natives), but it leaks a guard-language detail — a host doingtype(x) is int, isinstance checks, or interop with harel-rust (native scalars) gets a surprise.Fix
Normalize every CEL result to native Python at the single choke point —
cel.evaluatevia_from_cel— so no wrapper can escape the module. Covers all kinds (int/float/bool/string/bytes/map/list) and nested containers, which by construction reaches every boundary (esvs, snapshots,--json, observer, published payloads).Verify
int.tests/test_native_values.py: native type for every esv kind (incl. nested), and no celpy type anywhere in a snapshot.Implementation-only; spec (harel#32/#33) already merged, and per that spec no new engine conformance case is warranted (cross-language type identity isn't language-neutrally expressible;
--jsonconformance already enforces canonical JSON).