Skip to main content

Module execution_result

Module execution_result 

Source
Expand description

v2.81.0 — the flow-execution RESULT, in a module that reaches nothing.

THE THIRD INSTANCE OF THE SMELL, and the largest so far. AXON_VERSION (v2.81.0) lived in the flow executor; IngestProvenance (v2.81.0) lived in the OOXML reader; ServerExecutionResult and EnforcementSummaryWire lived in axon_server.rs — 29,734 lines of axum router. Same shape every time: a general concept parked in the specific module that first needed it, silently chaining everything downstream to that module’s dependencies.

What it chained here was not a leaf. ServerExecutionResult is the input of crate::wire_envelope::FlowEnvelope::from_execution_result (v2.0.0), and EnforcementSummaryWire is threaded through flow_dispatcher, flow_dispatcher::pure_shape and streaming_via_dispatcherthe core execution path. So axon run, which opens no socket, could not compile without the HTTP server, for two structs that contain no HTTP: eight counters, a policy slug, and an aggregation of step names and token totals.

Neither type is server-specific. server_execute was simply the first caller to need a place to put the answer. The name ServerExecutionResult is kept verbatim — it is crate-public since v2.0.0 and named by tests/wire_envelope_integration.rs and tests/epistemic_ownership_integration.rs — and axon_server re-exports both, so every existing call site (including axon-enterprise, which consumes axon::axon_server::ServerExecutionResult) keeps resolving.

This module must never acquire a dependency. Its whole value is that the execution path can name its own result type without linking a web framework.

Structs§

EnforcementSummaryWire
v1.24.0 — Wire-serializable mirror of crate::stream_effect_dispatcher::EnforcementSummary published on axon.complete per the D2 contract.
ServerExecutionResult
Server-side execution result.