feat: thread expression mode through evaluation (expression v3) - #337
Merged
Conversation
Bump expression to v3 and thread the per-session expression mode (context.private[:expression_mode], stamped by the consumer) into every internal evaluation: contract entry points accept a FlowRunner.Context (or a bare vars map for backwards compatibility, evaluating under :v2), and direct Expression call sites pass FlowRunner.expression_opts/1. A missing stamp degrades safely to :v2. This keeps flow_runner's Case/exit/log/simulator evaluations under the same per-journey semantics engage selects once expression v3 rolls out. The expression dep is temporarily a git pin on release/3-0-0 until the v2-compat mode ships in a tagged hex release (pre-publish TODO in mix.exs). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Santiago <santiagocardo80@gmail.com>
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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.
Purpose
Resolve
expressionmode at evaluation runtime.flow_runnerevaluates expressions itself (Case-block conditions, exits, logs, simulator output), so when consumers start selecting expression mode dynamically (onexpressionv2 → v3 transition),flow_runner's internal evaluations must honor the same mode — otherwise, they would evaluate its conditions under one semantics and its messages under another.Approach
Mode carrier:
context.private[:expression_mode](:v2 | :v3). Users stamp it when building the context. A missing stamp — old serialized contexts, third-party callers — degrades safely to:v2(today's behavior).expressionto v3 and adapts to its API (this part was already done — the dep resolves 3.0.0-rc.0's removals cleanly sinceflow_runnernever used the removed surfaces;evaluate_expression_block's rescue now speaksExpression.Error).FlowRunner.evaluate_expression/2,evaluate_expression_as_string!/2,evaluate_expression_block/2accept a%FlowRunner.Context{}(evaluatescontext.varsunder the stamped mode). Contract callback specs temporarily changed toFlowRunner.Context.t().FlowRunner.expression_opts/1translating a Context-or-map into expression options ([mode: :v2]or[]).%{context | vars: ...}so the mode is kept; the webhook block and 18 simulator sites passexpression_opts(...)explicitly (simulator via a nil-safe private helper). Sites that evaluate static config with no vars (whatsapp_template_messagedefault_language, one simulator pipe) are mode-independent and unchanged.Verification
test/flow_runner/expression_mode_test.exs(8 tests): mode resolution from private data,:v2/:v3/unstamped/bare-map behavior through each contract function, including the v2 datetime-coercion rendering.mix credo --strictandmix format --check-formattedclean, compile with--warnings-as-errors.🤖 Generated with Claude Code