Repository navigation
feat: carry a provider fault, and stop forwards faking ordinal 0 - #20
Merged
Merged
Conversation
The runtime grew a fault channel: a third response shape for a provider
that failed where the schema declares no error for it. The simulator is
a provider, so it needs to be able to produce one, and a client, so it
needs to be able to read one.
- `WireFraming::encode_response_fault` — the datagram framing's third
tag, JSON-RPC's reserved `-32603`.
- `jsonrpc_decode_response` no longer does `e.code as u16`
unconditionally. Only a code inside the ordinal space is a raised
schema error; the reserved negative codes are JSON-RPC's own, and
`-32603 as u16` was silently becoming ordinal 33205.
- `BehaviorKind::Fault` — "Fault (provider failed)". Unlike `Raise` it
applies to any non-one-way function, declared errors or not: a
function with no `!` previously had no way to fail at all.
- `CallResult::Fault` / `SimOutcome::Fault`, and `fault: true` on
`FrameDetail` so the inspector shows it rather than reporting the
frame as undecodable.
It also fixes a real bug. A forward whose upstream timed out or returned
an undecodable body replied to the outer caller with `ordinal: 0` and a
`{"error": "..."}` body — a *schema* error, which the outer client
decodes as whichever error happens to hold ordinal 0. That is a wrong
answer dressed as a failure. Those now fault.
Multi-`!` needed no change: `FnShape::throws` was already a `Vec` and
`Raise`'s config names an ordinal, so any declared error is reachable.
There is a test pinning that.
135 tests pass; clippy and fmt clean.
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.
Follows ComlineProject/runtime#11, which added a fault channel: a third
response shape for a provider that failed where the schema declares no error
for it. The simulator acts as both provider and client, so it needs both ends.
The channel
WireFraming::encode_response_fault— rendered per framing, as the runtimedoes it: the datagram framing's third tag, JSON-RPC's reserved
-32603 Internal error.jsonrpc_decode_responseno longer doese.code as u16unconditionally.Only a code inside the ordinal space is a raised schema error; the reserved
negative codes are JSON-RPC's own.
-32603 as u16was silently becomingordinal 33205, and
-32601("method not found") ordinal 33039.BehaviorKind::Fault— "Fault (provider failed)". UnlikeRaiseit appliesto any non-one-way function whether or not it declares errors, which is the
whole point: a function with no
!previously had no way to fail at all.CallResult::Fault,SimOutcome::Fault, andfault: trueonFrameDetailso the inspector shows a fault instead of reporting the frame as undecodable.
The bug it fixes
A forward whose upstream timed out, or returned a body that would not decode,
replied to the outer caller with
ordinal: 0and a{"error": "…"}body. Thatis a schema error: the outer client decodes it as whichever error happens to
hold ordinal 0 and hands its caller a wrong answer rather than a failure. Those
now fault.
Two sites still fabricate
ordinal: 0and are left alone deliberately:begin_forward's configuration refusals ("no connection X", "forwardingcycle", "X has no send") and the disabled-script stub. Each carries a message
the user needs, and a fault is opaque by design — there is nowhere else in the
engine to put the text. They want a diagnostic sink, which is its own change.
Multi-`!`
Needed no change.
FnShape::throwswas already aVec<ThrowShape>andRaise's config names an ordinal, so every declared error is reachable; thedefault seeds the first in declaration order. Pinned by
`a_function_that_throws_several_errors_can_raise_any_of_them`.
Verification
135 tests pass, clippy and fmt clean. New tests: a fault round-trips over every
framing in
TRANSPORT_MATRIX; a reserved JSON-RPC code is not read as anordinal; JSON-RPC's fault frame is byte-checked; a forwarded fault stays a
fault; the inspector renders one.
Note for the playground
call_result_jsonnow emits{"status":"fault"}and a frame detail can carryfault: true. The playground UI needs a case for each (a status chip and aframe badge) — not touched here.