92c790ffe5
* fix(tests): make mtime_invalidation and glm_5_3 tests order-independent (#7100) * fix: expose max reasoning for GPT-5.6 models * fix(recovery): do not reattach cancelling runs ACTIVE_RUNS tracks worker lifecycle, which is deliberately broader than "a turn a browser may attach to". cancel_stream() keeps the row as phase="cancelling" while the worker unwinds so a successor turn cannot start on top of it, but the client has already reached a terminal state for that stream: its run journal ends in a terminal event. The recovery lookups treated every same-session ACTIVE_RUNS row as attachable. An idle session holding a cancelling row therefore received a recovered server_turn_started on every /api/session/stream subscription: the client attached, replayed the terminal event, tore the renderer down, resubscribed, and the server replayed the same frame again. The result is an endless attach/replay loop that rebuilds the transcript repeatedly. Separate the two meanings instead of narrowing one call site: - api/config.py gains active_run_is_attachable() and active_run_cancel_is_stale() as the shared predicates. - active_stream_id_for_session() (browser recovery) returns attachable rows only; _session_has_active_turn() (busy check) keeps counting a fresh cancellation so a successor cannot overlap the unwinding worker. - _live_active_stream_id() applies the same rule to the hidden-tab status poller, on both the STREAMS and ACTIVE_RUNS paths. - routes._cancelled_run_is_stale() now delegates to the shared predicate rather than keeping a parallel copy of the staleness rule. - A cancelling row past a bounded unwind window with no live STREAMS channel is reclaimed from ACTIVE_RUNS and its stream owner released, so a wedged worker cannot suppress background wakeups forever. Age alone does not reclaim a row that still owns a live channel. Staleness anchors on cancelled_at, falling back to started_at, so a long-running turn cancelled moments ago is never treated as an orphan. tests/test_cancelling_run_not_attachable.py covers both directions of each rule. The six behavioral tests fail on the unpatched tree and pass with the fix; two targeted mutations (forcing the attachability predicate true, and disabling the staleness reaper) each turn the suite red. * docs(rfc): document cancellation attach/admission split Records the runtime contract introduced by the recovery fix in the WebUI run-state consistency RFC, so the distinction is discoverable instead of living only in code comments. - Adds ACTIVE_RUNS to the State Layers table as the worker-lifecycle registry, explicitly not the set of runs a browser may attach to. - Adds invariant 9: lifecycle-busy is not client-attachable. Cancellation splits the two meanings, recovery paths must exclude cancelling rows, and admission checks must keep counting them. - Documents the bounded cancellation-unwind window: reclamation needs both age and the absence of a live STREAMS channel, and staleness is anchored on the cancellation timestamp. - Extends the review checklist with the admission-vs-attachment question and the evidence required when changing a reclamation window. * docs(changelog): note #7096 cancelling-run reattach, #7083 GPT-5.6 max reasoning, #7101 test order-independence --------- Co-authored-by: webtecnica <webtecnica@gmail.com> Co-authored-by: Abdulrahman Elkenany <boudy.elkenany123@gmail.com> Co-authored-by: allenliang2022 <allenliang2022@users.noreply.github.com> Co-authored-by: n <a@n>
RFCs
This directory holds design documents for hermes-webui features that are worth thinking through in writing before (or alongside) implementation — typically when the change touches durability, recovery, schema, or cross- cutting infrastructure.
Conventions
-
One file per RFC. Filename is the topic (kebab-case), not a number.
-
Top of every RFC carries a small header:
- **Status:** Proposed | Accepted | Implemented | Withdrawn - **Author:** @github-handle - **Created:** YYYY-MM-DD -
Sections usually include: Problem, Goals, Non-goals, Proposal, Open questions, Rollout plan. Skip what doesn't apply.
-
An RFC is a starting point for review. Comments and revisions land via PR edits, not separate discussion threads.
-
An RFC documents a design direction. It is not an invitation to file implementation PRs against fragments of it. Before opening any PR that implements an accepted RFC, confirm with a maintainer in the tracking issue that the implementation slice is wanted and that no other contributor is already building it. Speculative implementations of RFC fragments without a confirmed integration site will be held.
When to file an RFC
- The change is large enough that you want consensus before writing code.
- The change touches data-at-rest formats or recovery semantics.
- The change introduces a new architectural primitive (journal, queue, scheduler, cache layer) that other features will build on.
- A reviewer asks for one during code review.
When in doubt, just ship the code — small features don't need RFCs. First-time contributor RFCs should be discussed in an issue before opening a PR.
Current RFCs
hermes-run-adapter-contract.md— #1925 event/control contract, runtime-state ownership matrix, acceptance catalog, and reversible migration gates for moving WebUI execution behind an explicit adapter boundary.webui-run-state-consistency-contract.md— #2361 consistency rules for keeping transcript, model context, live streams, replay, compression, and session metadata coherent during active and recovered WebUI runs.live-to-final-assistant-replies.md— #3400 accepted product model for long-running assistant replies, live process prose, tool activity, recovery, terminal outcomes, display projections, and the final-answer boundary.transparent-stream-activity-mode.md— #3820 implemented opt-in display mode for power users who need a transparent, chronological Thinking / progress / tool-call stream alongside the default Compact Worklog and opt-in Final answer only projections.stable-assistant-turn-anchors.md— #3926 implemented frontend presentation/reconciliation model for anchoring live assistant activity, settled final answers, replay, and all activity display modes to one assistant turn; remaining hardening is tracked under #3400.canonical-session-resolution.md— #2361 focused contract for resolving URL, query parameter, localStorage, sidebar, and compression-lineage session IDs to one canonical visible chat target.turn-journal.md— Crash-safe WebUI turn journal for recovering interrupted chat submissions.webui-pending-intent-controls.md— #3058 control-surface companion to #3400 for Queue, Steer, Stop-and-send, Interrupt, and leftover-steer inputs submitted while a long-running agent session is active.session-sse-contract-v1.md— #4812 Proposed contract vocabulary, replay identity, event taxonomy, cursor/resume semantics, and implementation gates forGET /api/sessions/{session_id}/events.