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
Follow-up to #338 (PR #455). The new compile-time fallback-compatibility checks in compile_flow() — missing_fallback_tool, fallback_unknown_target_key, fallback_type_mismatch, fallback_missing_required_input — are only exercised for linear Flows. DAGFlow fallbacks are not equivalently covered at compile time.
Background
Runtime is already handled.DAGFlow fallback execution routes through _apply_on_error_async (chainweaver/executor.py), which validates inputs against the fallback's own schema and records StepRecord.fallback_tool_name. So the runtime trace attribution from Investigation: validate fallback tool inputs against the fallback's input schema #338 already applies to DAGs.
Compile time is the gap.compile_flow() iterates flow.steps and accumulates context_fieldslinearly (chainweaver/compiler.py). For a DAGFlow, the set of inputs available to a step is governed by the dependency graph, not linear position — so _validate_fallback_inputs either does not run against a correct context model for DAG steps or is not invoked for them at all.
Confirm how (and whether) compile_flow() is intended to validate DAGFlow today — the current context model assumes linear accumulation.
Build the per-step available-context set from the DAG's resolved dependency order before invoking the existing _validate_fallback_inputs helper.
Reuse _validate_fallback_inputs so the linear and DAG paths share one contract.
Acceptance criteria
Compiling a DAGFlow with an incompatible fallback (missing tool, unknown mapped key, missing required input, type mismatch) surfaces the same fallback_*CompilationErrors as the linear path.
A compatible DAGFlow fallback compiles clean.
Documented fallback semantics note that compile-time checks apply to both linear and DAG flows.
Test plan
DAG compiler tests mirroring TestFallbackInputCompatibility (tests/test_compiler.py).
An async DAG execution test asserting fallback_tool_name attribution end-to-end.
Summary
Follow-up to #338 (PR #455). The new compile-time fallback-compatibility checks in
compile_flow()—missing_fallback_tool,fallback_unknown_target_key,fallback_type_mismatch,fallback_missing_required_input— are only exercised for linearFlows.DAGFlowfallbacks are not equivalently covered at compile time.Background
DAGFlowfallback execution routes through_apply_on_error_async(chainweaver/executor.py), which validates inputs against the fallback's own schema and recordsStepRecord.fallback_tool_name. So the runtime trace attribution from Investigation: validate fallback tool inputs against the fallback's input schema #338 already applies to DAGs.compile_flow()iteratesflow.stepsand accumulatescontext_fieldslinearly (chainweaver/compiler.py). For aDAGFlow, the set of inputs available to a step is governed by the dependency graph, not linear position — so_validate_fallback_inputseither does not run against a correct context model for DAG steps or is not invoked for them at all.Proposed implementation
compile_flow()is intended to validateDAGFlowtoday — the current context model assumes linear accumulation._validate_fallback_inputshelper._validate_fallback_inputsso the linear and DAG paths share one contract.Acceptance criteria
DAGFlowwith an incompatible fallback (missing tool, unknown mapped key, missing required input, type mismatch) surfaces the samefallback_*CompilationErrors as the linear path.DAGFlowfallback compiles clean.Test plan
TestFallbackInputCompatibility(tests/test_compiler.py).fallback_tool_nameattribution end-to-end.Relates to #338.