Skip to content

Fault-recovery bench: six PEAK runs of the shipped recovery recorded - #554

Open
thebhef wants to merge 3 commits into
task163-recoveryfrom
task163-recovery-docs
Open

thebhef wants to merge 3 commits into
task163-recoveryfrom
task163-recovery-docs

Conversation

@thebhef

@thebhef thebhef commented Oct 6, 2026

Copy link
Copy Markdown
Owner

Fault-recovery bench: six PEAK runs of the shipped recovery recorded

Trials 7–12 of 2026-10-06, close-then-open shipped as the sidecar's own
bus-off recovery (strategy sidecar): bus-off recovered 3/3 (trials 8,
10, 12 — twice at the plug, once at the pull), error-passive recovered by
itself 3/3 (7, 9, 11), the stuck transmit queue flushed and resumed (7, 8).
Run 7's 1.8 idle hours before the pull are trimmed from its events file.

Co-Authored-By: Claude Fable 5.1 noreply@anthropic.com

Bench: adapter-clock timeline and a bus_back event; ADR 0039 close-before-open evidence

Phase 9d. The bench now tracks when each channel's own bus-error
episode and the pull/bus-off/reopen/recovered stages happened on the
adapter's own clock, not just the bench's software detection: a
bus_back event fires once the channel under test reads active with
its episode closed and hears the partner again -- a reopened channel
has no backlog, so this is close to live, unlike recovered, which
waits out whatever backlog the partner is still draining. The verdict
now prints and records this timeline (table.md and the verdict event),
plus how far behind wall clock the slower channel's last error report
arrived at bus back.

Fixed along the way: the timeline's own "recovered" entry disagreed
with the verdict's by about a second, because recovered is confirmed
only after its clean run has held for recovery_window_s -- back-dating
the wall-clock reading to when the run actually started (what
run_start_t reports) rather than to the confirming frame's arrival
fixes it.

ADR 0039's 2026-10-06 amendment gains the two findings the live PEAK
runs established but the amendment did not yet say: a pull alone does
not take a controller bus-off (an error-passive transmitter's
acknowledge errors do not raise its TEC; bus-off came only from
bit/form/stuff errors at the connector), and the measured recovery
time (active within about 1.6 s of bus-off), with the strategy-ladder
verdict table as evidence. ADR 0060's pointer to ADR 0039 already
covered close-before-open and the bus-off-refusal re-arm, so it is
unchanged.

Comment fix: driver_python_can.py's _BUS_OFF_TEXTS block and
bench/fake.py's open-failure comment both named "the owner's bench" as
the source of a claim; both now state the PCAN-Basic rule on its own
text, citing ADR 0039 where fake.py needs a reason.

Sidecar README's Fault recovery bench section documents the bus_back
event, the timeline, that wait's own --timeout is separate from run's,
and a short paragraph on what the strategy ladder showed on PEAK.

Checks (sidecar-scoped; see report): ruff check/format, mypy, full
pytest (372 passed) all clean; comment-references grep clean.

This was referenced Oct 6, 2026
@thebhef
thebhef force-pushed the task163-recovery-docs branch from b5e0065 to 02fbb5e Compare October 7, 2026 14:30
@thebhef
thebhef marked this pull request as ready for review October 14, 2026 21:09
@thebhef
thebhef force-pushed the task163-recovery-docs branch from 02fbb5e to d7f6f79 Compare October 15, 2026 00:12

thebhef commented Oct 22, 2026 •

Copy link
Copy Markdown
Owner Author

Merge activity

thebhef and others added 3 commits October 26, 2026 15:01
Trials 7–12 of 2026-10-06, close-then-open shipped as the sidecar's own
bus-off recovery (strategy `sidecar`): bus-off recovered 3/3 (trials 8,
10, 12 — twice at the plug, once at the pull), error-passive recovered by
itself 3/3 (7, 9, 11), the stuck transmit queue flushed and resumed (7, 8).
Run 7's 1.8 idle hours before the pull are trimmed from its events file.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…fore-open evidence

Phase 9d. The bench now tracks when each channel's own bus-error
episode and the pull/bus-off/reopen/recovered stages happened on the
adapter's own clock, not just the bench's software detection: a
bus_back event fires once the channel under test reads active with
its episode closed and hears the partner again -- a reopened channel
has no backlog, so this is close to live, unlike recovered, which
waits out whatever backlog the partner is still draining. The verdict
now prints and records this timeline (table.md and the verdict event),
plus how far behind wall clock the slower channel's last error report
arrived at bus back.

Fixed along the way: the timeline's own "recovered" entry disagreed
with the verdict's by about a second, because recovered is confirmed
only after its clean run has held for recovery_window_s -- back-dating
the wall-clock reading to when the run actually started (what
run_start_t reports) rather than to the confirming frame's arrival
fixes it.

ADR 0039's 2026-10-06 amendment gains the two findings the live PEAK
runs established but the amendment did not yet say: a pull alone does
not take a controller bus-off (an error-passive transmitter's
acknowledge errors do not raise its TEC; bus-off came only from
bit/form/stuff errors at the connector), and the measured recovery
time (active within about 1.6 s of bus-off), with the strategy-ladder
verdict table as evidence. ADR 0060's pointer to ADR 0039 already
covered close-before-open and the bus-off-refusal re-arm, so it is
unchanged.

Comment fix: driver_python_can.py's _BUS_OFF_TEXTS block and
bench/fake.py's open-failure comment both named "the owner's bench" as
the source of a claim; both now state the PCAN-Basic rule on its own
text, citing ADR 0039 where fake.py needs a reason.

Sidecar README's Fault recovery bench section documents the bus_back
event, the timeline, that wait's own --timeout is separate from run's,
and a short paragraph on what the strategy ladder showed on PEAK.

Checks (sidecar-scoped; see report): ruff check/format, mypy, full
pytest (372 passed) all clean; comment-references grep clean.
…,<1.81)

The lock's recorded requires-dist for the wire path dependency lagged its
pyproject, so every plain `uv run` rewrote the line. One-line sync; the
resolved wheel is unchanged.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@thebhef
thebhef force-pushed the task163-recovery-docs branch from d7f6f79 to 769cb9a Compare October 26, 2026 22:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant