bug: anchor-poison threshold (default 7) is unreachable because the retry circuit trips at a hardcoded 2 — dead previous_response_id is never abandoned on 1.24.0-beta.3

[nickwilson159]

Pre-flight checklist

• I searched open and closed issues and confirmed this is not a duplicate.
• I am running a supported codex-lb version.
• I can reproduce the problem with the steps below.

Closest prior art, and why this is distinct:

• bug: HTTP bridge misclassifies upstream error frames as stream_incomplete; retry circuit + operation ledger wedge sessions permanently ("cooling down" 503 loop) #1830 (closed, fixed by fix(http-bridge): classify recovery error frames and poison same-anchor eventless failures #1841 in 1.24.0-beta.3) — same 503 cooling down surface. This report reproduces on b3, with fix(http-bridge): classify recovery error frames and poison same-anchor eventless failures #1841 in the build. fix(http-bridge): classify recovery error frames and poison same-anchor eventless failures #1841 bounded the wedge (it now self-clears after a cooldown instead of persisting) but did not remove the mechanism, and the misclassification it targeted is still observable (see step 2 below).
• fix(proxy): name the pre-response eventless timeout honestly and derive its budget from settings #1633 (open) — also about a hardcoded ~60s and honest classification, but for the pre-response.created silence watchdog. That is a different timer from the retry-circuit backoff described here; the two are complementary.
• bug: previous_response_id continuation loops after invalid_request_error and WebSocket close on 1.23.0 #1816 (closed, fix(proxy): recognize the terse upstream previous_response_id rejection #1817) — previous_response_id continuation loops on 1.23.0, about recognising the terse upstream rejection. This report is about threshold arithmetic, not classification recognition.
• No issue mentions anchor_poison_failure_threshold.

codex-lb version

1.24.0-beta.3 (confirmed via x-app-version response header)

Deployment method

uvx (codex-lb)

Client used against codex-lb

Codex app (desktop / web) — Codex Desktop/0.148.0-alpha.15 (Windows 10.0.26200; x86_64)

ChatGPT account plan(s) involved

Pro (pool of 2 accounts, both status=active throughout)

Model(s) involved

gpt-5.6-sol

What happened?

Summary: http_responses_session_bridge_anchor_poison_failure_threshold defaults to 7, but the retry circuit that gates the same counter trips at a hardcoded 2. The poison threshold is therefore effectively unreachable, so a dead previous_response_id is never abandoned and the bridge re-injects it indefinitely.

Both values are compared against the same counter. In app/modules/proxy/_service/http_bridge/upstream_events.py:

consecutive_failures = await self._record_http_bridge_retry_circuit_failure_for_attempt_selection(
    session, detail=retry_circuit_detail, selection=retry_circuit_attempt_selection,
)
poison_candidate_detail = _http_bridge_anchor_poison_detail(retry_circuit_detail)
if (
    poison_candidate_detail is not None
    and observed_response_events == 0
    and consecutive_failures is not None
    and consecutive_failures
    >= _service_get_settings().http_responses_session_bridge_anchor_poison_failure_threshold
):
    poison_detail = poison_candidate_detail

and in app/modules/proxy/_service/http_bridge/retry_circuit.py:

_HTTP_BRIDGE_RETRY_CIRCUIT_FAILURE_THRESHOLD = 2
_HTTP_BRIDGE_RETRY_CIRCUIT_BASE_BACKOFF_SECONDS = 60.0
_HTTP_BRIDGE_RETRY_CIRCUIT_MAX_BACKOFF_SECONDS = 600.0

Once the circuit opens at consecutive_failures == 2, subsequent requests on that bridge key are refused before reaching upstream (continuity_fail_closed reason=retry_circuit_cooldown_continuity_bound), so they do not record circuit failures. The counter can then only advance once per half-open probe, i.e. roughly once per cooldown, with the backoff escalating from 60s toward the 600s ceiling. Reaching 7 would take approximately five further open→cooldown→half-open cycles spanning on the order of 25 minutes. No interactive client waits that long, so in practice the anchor is never poisoned and the same dead anchor is retried forever.

The observed cascade, from one incident:

1. The stored anchor goes stale. Upstream reports previous_response_not_found.
2. The bridge records it as detail=stream_incomplete. Both appear in the same second for the same bridge key — the websocket surface classifies correctly while the bridge path does not. This is the residual bug: HTTP bridge misclassifies upstream error frames as stream_incomplete; retry circuit + operation ledger wedge sessions permanently ("cooling down" 503 loop) #1830 described, still present with fix(http-bridge): classify recovery error frames and poison same-anchor eventless failures #1841 in the build.
3. The bridge re-injects the same dead anchor and discards the client's real context: original_items=248 trimmed_to=6, with fresh_replay_available=false. The client had supplied the entire conversation.
4. Second consecutive failure opens the circuit: event=opened failures=2 cooldown_seconds=60.0 detail=stream_incomplete.
5. The client emitted 10 requests in 10 seconds, every one answered 503 ... cooling down after repeated upstream timeouts; retry shortly. Because the turn is continuity-bound it cannot fail over to the second, healthy account. The client aborts the session long before the 60s cooldown elapses.

Net effect: the message says "retry shortly", but the shortest possible cooldown (60s) is far longer than the client's retry budget (~10-16s observed), and because the anchor is never poisoned, waiting out the cooldown just re-wedges on the next turn.

What did you expect to happen?

• The anchor-poison path should be reachable at its documented default. Either the poison threshold should be less than or equal to the circuit threshold, or poisoning should be evaluated independently of the circuit gate.
• A dead previous_response_id should be abandoned rather than re-injected once upstream has rejected it with previous_response_not_found.
• _HTTP_BRIDGE_RETRY_CIRCUIT_FAILURE_THRESHOLD / _BASE_BACKOFF_SECONDS should be settings-derived, so the cooldown can be aligned with real client retry budgets (this is the same class of fix as fix(proxy): name the pre-response eventless timeout honestly and derive its budget from settings #1633).
• When the bridge has just trimmed a full client history down to an anchor, and that anchor is rejected with zero response events, failing closed discards recoverable information the client already sent.

Steps to reproduce

1. Run uvx --from "codex-lb==1.24.0b3" codex-lb with a 2-account Pro pool, defaults otherwise.
2. Drive a long Codex Desktop conversation through http://127.0.0.1:2455/backend-api/codex until the HTTP responses session bridge holds a latest_response_id anchor.
3. Cause that anchor to become unknown upstream (observed here after an abrupt upstream websocket drop mid-turn; upstream then answers previous_response_not_found).
4. Continue the same conversation.
5. Observe two consecutive terminal_error detail=stream_incomplete, the circuit opening at failures=2, and a burst of 503 ... cooling down. Observe that http_bridge_retry_circuits.consecutive_failures stalls at 2 and never approaches 7, so durable_anchor_poisoned never fires.

Relevant logs

Identifiers truncated; response ids shortened.

15:34:25 INFO  http_bridge_event event=fresh_reattach_anchor_injected bridge_key=sha256:99f1afc14b46 detail=response_id=resp_0f07fa9a...
15:34:25 WARN  continuity_fail_closed surface=websocket_stream reason=previous_response_not_found
               upstream_error_code=previous_response_not_found
               diagnostics=previous_response_source=proxy_injected fresh_replay_available=false
15:34:25 WARN  http_bridge_event event=terminal_error bridge_key=sha256:99f1afc14b46 detail=stream_incomplete
15:34:25 INFO  http_bridge_event event=previous_response_recover_local detail=outcome=local_rebind_after_local_error
15:34:25 INFO  http_bridge_retry_circuit event=half_open bridge_key=sha256:99f1afc14b46 failures=1

15:34:30 WARN  continuity_fail_closed surface=websocket_stream reason=previous_response_not_found
               upstream_error_code=previous_response_not_found
               diagnostics=previous_response_source=client_supplied fresh_replay_available=false
15:34:30 WARN  http_bridge_event event=terminal_error bridge_key=sha256:99f1afc14b46 detail=stream_incomplete

15:34:31 INFO  session_anchor_injected response_id=resp_0f07fa9a...          <-- same dead anchor re-injected
15:34:31 INFO  store_context_input_trimmed original_items=248 trimmed_to=6 previous_response_id=resp_0f07fa9a...

15:34:33 WARN  http_bridge_event event=reader_failure bridge_key=sha256:99f1afc14b46 pending=1 detail=stream_incomplete
               error_message=Upstream websocket closed before response.completed: no close frame received or sent
               response_events_seen=0 transport_classification=websocket_transport_error
15:34:33 ERROR proxy_error_response status=502 code="stream_incomplete"
15:34:33 WARN  http_bridge_retry_circuit event=opened bridge_key=sha256:99f1afc14b46 failures=2 cooldown_seconds=60.0 detail=stream_incomplete

15:34:39 WARN  continuity_fail_closed surface=http_bridge reason=retry_circuit_cooldown_continuity_bound
15:34:39 ERROR proxy_error_response status=503 code="upstream_request_timeout"
               message="HTTP responses session bridge is cooling down after repeated upstream timeouts; retry shortly."
   ... 10 x 503 between 15:34:39 and 15:34:49 ...

Persisted circuit state, showing the counter stalled at the circuit threshold:

http_bridge_retry_circuits:
  session_key_kind      = thread_header
  consecutive_failures  = 2          <-- never advances toward the poison threshold of 7
  cooldown_until_epoch  = updated_at_epoch + 60.0
  last_detail           = stream_incomplete

Configuration / environment

All defaults; no .env.local. Windows 11, SQLite store. Two Pro accounts, both active, neither rate-limited or blocked.

Additional context

Workaround that appears to address it, for anyone hitting this before a fix:

CODEX_LB_HTTP_RESPONSES_SESSION_BRIDGE_ANCHOR_POISON_FAILURE_THRESHOLD=2

This aligns the poison threshold with the hardcoded circuit threshold so the dead anchor is abandoned on the same failure that opens the circuit. The cost is more eager anchor discard, hence weaker prompt-cache reuse. It is a mitigation, not a fix — the underlying coupling remains.

Note also that a restart does not clear an already-wedged session, because the anchor is persisted in http_bridge_sessions.latest_response_id; the http_bridge_* tables have to be cleared.

Two smaller observations from the same investigation, offered in case they are useful:

• store_context_input_trimmed original_items=248 trimmed_to=6 immediately before a fresh_replay_available=false failure looks like a missed recovery opportunity: the client had just supplied the full history that the bridge then reported as unavailable. http_responses_session_bridge_ambiguous_continuation_recovery_mode=client_full_history_once exists for this, but is documented as at-least-once, which is a strong deterrent for a default.
• On this deployment the abrupt-drop signature (no close frame received or sent) accounted for 105 of 132 stream_incomplete events on 1.23.0 and continued at a similar daily rate on b3, which is what keeps feeding step 1 of the cascade.

Happy to supply fuller logs, the raw http_bridge_* table dump, or to test a patch.

[kevinsslin]

Independent reproduction on a different platform and deployment method. The threshold arithmetic described here holds, and the counter stalls at exactly 2 as reported.

Environment

Different from the original report in every axis except the version and model class:

	original report	this reproduction
OS	Windows 11	Ubuntu 24.04 LTS (kernel 6.8.0-40), Alibaba Cloud ECS
Deployment	uvx	systemd unit, pinned venv install of codex-lb==1.24.0b3
Client	Codex Desktop 0.148.0-alpha.15	Codex CLI 0.148.0
Accounts	Pro pool of 2	pool of 2, both status=active
Store	SQLite	SQLite (3.6 GB)

Version confirmed via x-app-version: 1.24.0-beta.3. Model gpt-5.6-sol.

Observed sequence

Trigger was an abrupt upstream websocket drop mid-turn, response_events_seen=0:

13:21:52 WARN  http_bridge_event event=reader_failure bridge_key=sha256:503fa2531ad7 pending=1
               detail=stream_incomplete
               error_message=Upstream websocket closed before response.completed: no close frame received or sent
               response_events_seen=0 transport_classification=websocket_transport_error
13:21:53 INFO  http_bridge_retry_circuit event=half_open bridge_key=sha256:503fa2531ad7 failures=1
13:22:00 WARN  http_bridge_event event=reader_failure bridge_key=sha256:503fa2531ad7 detail=stream_incomplete
13:22:00 WARN  http_bridge_retry_circuit event=opened bridge_key=sha256:503fa2531ad7 failures=2
               cooldown_seconds=60.0 detail=stream_incomplete
13:22:05 WARN  continuity_fail_closed surface=http_bridge reason=retry_circuit_cooldown_continuity_bound
13:23:49 WARN  continuity_fail_closed surface=websocket_stream reason=previous_response_not_found
               upstream_error_code=previous_response_not_found
               diagnostics=previous_response_source=proxy_injected fresh_replay_available=false

The bridge had trimmed the client's full history to the anchor immediately before this, matching step 3 of the report:

store_context_input_trimmed original_items=149 trimmed_to=4

Persisted row, counter stalled at the circuit threshold exactly as described:

session_key_kind      = thread_header
consecutive_failures  = 2
cooldown_until_epoch  = updated_at_epoch + 60.0
last_detail           = stream_incomplete

consecutive_failures never advanced past 2 over the whole incident, so durable_anchor_poisoned never fired and the anchor was never abandoned.

A config-level mitigation exists, with limits

http_responses_session_bridge_anchor_poison_failure_threshold is a settings field with ge=1, so it can be lowered to meet the circuit threshold without a code change:

CODEX_LB_HTTP_RESPONSES_SESSION_BRIDGE_ANCHOR_POISON_FAILURE_THRESHOLD=2

The poison check in upstream_events.py reads the count returned by _record_http_bridge_retry_circuit_failure_for_attempt_selection in the same block, so at 2 >= 2 the poison fires on the second recorded failure, at the same moment the circuit opens, and _abandon_durable_http_bridge_continuity drops the dead anchor. This is the "poison threshold should be less than or equal to the circuit threshold" option from the issue, reachable today as an operator setting.

Two limits worth recording, in case they matter for how the real fix is shaped:

1. Poisoning does not clear the retry-circuit row. _clear_http_bridge_retry_circuit has a single call site, gated on event_type == "response.completed". So after the anchor is abandoned the key still carries failures=2 until one turn completes, and the client still sees up to one 60s cooldown before the first admitted probe.

2. The suppression that clients actually observe during that window does not come from the cooldown branch. In _http_bridge_precreated_retry_allowed the half-open branch returns False without emitting http_bridge_retry_circuit event=suppressed; only the cooldown branch logs it. Across this incident there were repeated submit_retry_circuit_suppressed detail=hard_key_cooldown with zero event=suppressed, which lines up with the 103-vs-0 measurement in fix(proxy): stop hard bridge keys wedging on a leaked half-open probe and a rejected continuity anchor #1857. The load-time arithmetic that fix(proxy): stop hard bridge keys wedging on a leaked half-open probe and a rejected continuity anchor #1857 identifies is present verbatim in b3:

cooldown_remaining = max(0.0, persisted.cooldown_until_epoch - now_epoch)
persisted_cooldown_until = now_monotonic + cooldown_remaining

With an elapsed durable cooldown this yields a deadline that is non-zero and in the past simultaneously, which the admission check reads as "a cooldown just ended" and converts into a 600s half-open lease.

So the threshold change makes the poison path reachable, but on its own it does not remove the wedge that #1857 describes. They look complementary rather than overlapping.

[kevinsslin]

Follow-up after running the ANCHOR_POISON_FAILURE_THRESHOLD=2 workaround from my earlier comment for a full day. Short version: it does what I claimed it does, and it is not enough. Posting the numbers because they narrow where a real fix has to sit.

Setup. 1.24.0-beta.3, ..._AMBIGUOUS_CONTINUATION_RECOVERY_MODE=server_anchored_replay_once, threshold 2 for the whole window. Comparison is the 30.0 h immediately before the change, same host, same client, same two accounts.

The threshold change works as designed

durable_anchor_poisoned goes from 0 occurrences before to 29 after, with detail=repeated_zero_event_stream_incomplete. Nothing else on that path changed, and the pre-change window did contain operations that reached 2 consecutive failures (2 retry-circuit opens), so those are exactly the events that now poison instead of being carried. _abandon_durable_http_bridge_continuity fires and the dead anchor does get dropped.

It does not reduce what the client feels

The two windows differ by about 15x in bridge traffic (460 reuses over 30.0 h, then 7073 over 12.7 h), so raw counts are not comparable. Per 100 bridge session reuses:

per 100 reuses	before (threshold 7)	after (threshold 2)
retry circuit opened	0.43	0.41
previous_response_not_found	7.4	2.3
eventless reader_failure retries	2.2	1.2

Being fair to the workaround: not_found and eventless retries per reuse both fell, which is consistent with the poison dropping dead anchors sooner. But circuit opens per reuse did not move at all. That is the number that matters, because the open circuit is what reaches the client as 503 ... cooling down, and it is why the workaround did not change my day to day.

Every genuine mid-stream kill still escalates

13 reader_failure events with response_events_seen > 0 and transport_classification=websocket_transport_error in the 12.7 h window. Counting what follows each one within 6 minutes:

kill time         events       nf      ev0  poison   opened
08-21 14:53:04         3        8        4       2        2
08-21 14:58:32        96        8        7       3        3
08-21 15:02:24         5        4        5       2        2
08-21 15:43:09         2        4        2       1        1
08-21 17:12:02       299        4        2       1        1
08-21 17:38:54         2        6        3       1        1
08-21 17:51:09        19        4        2       1        1
08-21 19:30:04      1094        4        2       1        1
08-21 19:35:23         2        6        4       2        2
08-21 21:30:01       483        4        2       1        1
08-21 21:59:09         3        4        2       1        1
08-21 23:01:18      4082       19       10       0        0
08-22 00:58:38         3       10        6       1        1

kills=13  escalated=13  opened circuit=12
mean per kill: not_found 6.5  ev0 3.9  poison 1.3  opens 1.3

13 of 13 escalate, 12 of 13 open the circuit. One upstream socket drop costs 6.5 previous_response_not_found responses and 3.9 eventless retries on average. The 23:01 row is the one to look at: 4082 events received, the worst escalation of the set, and it never poisoned at all. So poisoning is not reliably reached on the cases that hurt most.

The mechanism is visible in the logs and matches the trimming line in my first comment. The anchor the proxy replays is dead upstream, store_context_input_trimmed then trims the resend down against that dead anchor, upstream never emits response.created, and the next attempt therefore presents as a fresh eventless failure rather than as a stale anchor. Worst trim in this window was original_items=602 trimmed_to=3. That log line fired 6936 times in 12.7 h.

Counter-experiment: client_full_history_once is much worse, and the reason is structural

I tried it as a candidate fix on the same host. 15 minutes, 95 bridge reuses, 57 status=503. Against the threshold-2 window that is 60 per 100 reuses versus 0.06, so about three orders of magnitude worse. Reverted immediately.

The cause is that the recovery mode is tested by identity in three independent gates in http_bridge/request_submit.py:

• _http_bridge_client_full_history_recovery_enabled matches client_full_history_once
• _http_bridge_server_anchored_replay_enabled matches {server_anchored_replay_once, server_indefinite_recovery}
• _http_bridge_operation_fence_for_hard_continuity_enabled matches {server_anchored_replay_once, server_indefinite_recovery}

Selecting client_full_history_once therefore also disarms the #1739 operation fence and the server anchored replay. Whatever the right fix here turns out to be, that mode is not a usable mitigation today, and if the coupling is not intended then those three gates probably should not key off the same enum independently.

Two diagnostics defects that made this much harder to read

Both are small, and both sit on the exact paths this issue's evidence runs through.

1. surface=websocket_stream is a hardcoded literal. websocket/helpers.py:1332, :1337 and :1365, inside _rewrite_websocket_continuity_corruption_event. The HTTP bridge calls that helper at http_bridge/upstream_events.py:2269. Every one of my requests is a bridge request, and 163 of the 167 continuity_fail_closed lines in the window say surface=websocket_stream. Anyone reading these logs, including me in my first comment above, will read bridge failures as websocket-transport failures.

2. previous_response_source=client_supplied in those lines is usually not the client. _websocket_previous_response_source (websocket/helpers.py:1222) returns client_supplied whenever request_state.proxy_injected_previous_response_id is falsy. The local_previous_response_error recovery path never sets it: streaming.py:3311 does retry_previous_response_id = request_state.previous_response_id, so the proxy replays its own anchor, and then streaming.py:3407 builds retry_request_state and copies seven operation_* fields onto it but not that flag. Compare streaming.py:2550, which does set it on the other recovery path. So the 77 client_supplied lines in my window are largely, possibly entirely, proxy-injected anchors reported as client-supplied.

That second one may not be cosmetic. The same flag gates _http_bridge_request_state_wedged_reattach at quarantine.py:87, so the retry path also cannot be recognised as the #1534 wedge shape.

Happy to split the two diagnostics items out as their own small issues if you would rather keep this thread on the amplification itself.

[kevinsslin]

Correction to my previous comment. I had a second pass done over the causal chain and two things I asserted are wrong. The measurements stand; the mechanism I attached to them does not. The corrected version points at a smaller fix, so this is worth getting right.

What I got wrong

1. response_events_seen is not the failing request's own counter. It is a session-wide maximum:

# app/modules/proxy/_service/http_bridge/upstream_events.py:1511
response_events_seen = max(
    (request_state.response_event_count for request_state in session.pending_requests),
    default=0,
)

So response_events_seen=4082 can mean a sibling request on the same multiplexed session saw 4082 events while the request that actually failed saw none. I called those 13 lines "genuine mid-stream kills" on the strength of that field. That inference is not supported. The 13 counts are still 13 real reader failures, and the escalation table still measures what follows them, but they are not established to be mid-stream kills of the recovering request.

This actually matters in the opposite direction from what I assumed. A request that has already yielded output downstream never reaches the recovery machinery at all, because of the guard at streaming.py:2911:

if yielded_any:
    yield _partial_output_proxy_error_event_block(...)
    return

That is deliberate and pinned by test_stream_via_http_bridge_does_not_rebind_after_downstream_visible. So recovery only ever runs for requests that saw zero events, and for those the response_event_count == 0 gate at streaming.py:3146 is satisfied rather than violated.

2. The over-trim does not happen on the anchored replay. I said the proxy replays the dead anchor and store_context_input_trimmed then trims that replay. It does not. The trim writes to submit_payload (streaming.py:2749) and leaves effective_payload alone, while the replay sends retry_payload = effective_payload (streaming.py:3297), which is the pre-trim body. The anchored replay therefore ships the anchor plus the full history.

The 602 -> 3 trim is real, but it lands on the client's next turn. durable_lookup.latest_response_id still holds the dead anchor, the fresh-reattach path re-injects it (streaming.py:1614-1638), session hydration copies the stored count and fingerprint across (streaming.py:2601-2621), and the trim at streaming.py:2736-2765 then matches the prefix and strips it. Nothing in that block consults whether the anchor is still alive upstream.

What survives

Everything measured: the per-100-reuse table, the flat circuit-open rate, the escalation counts, the client_full_history_once result, and both diagnostics defects. So does the end state, which I had right: the not-found never presents as a stale anchor, so the next attempt looks like a fresh eventless failure.

The sharper diagnosis

The reason the dead anchor survives is narrower than I said, and it is not the threshold arithmetic in this issue's title.

An explicit upstream previous_response_not_found is the strongest possible evidence that durable_lookup.latest_response_id is garbage, and the code currently throws that evidence away twice over:

1. It never reaches the poison counter. Poisoning only counts reader failures whose detail maps through _HTTP_BRIDGE_ANCHOR_POISON_DETAILS (retry_circuit.py:41-44), which contains only stream_idle_timeout and stream_incomplete, and only when observed_response_events == 0. A not-found arrives as a terminal upstream event, not a reader failure, so it contributes nothing at any threshold. Lowering the threshold to 2 cannot help with this, which is consistent with what I measured: the threshold change moved the poison count but not the circuit-open rate.

2. It is masked before anyone can see it. _websocket_continuity_error_fields (websocket/helpers.py:1202-1209) only emits the real classifier when expose_stale_previous_response_classifier is true, and that flag is set exclusively in websocket/mixin.py. On the HTTP bridge it keeps its default of False (support.py:1011), so every bridge not-found is rewritten to stream_incomplete. The bridge tells itself a stale-anchor rejection is a transport failure.

So the anchor is denied by upstream, the denial is relabelled as a transport error, it is excluded from the mechanism designed to retire dead anchors, and the anchor is then re-injected into the next turn and trimmed against.

Implication for the fix

This changes what I was going to propose. I had been looking at adding another anchor-free dispatch inside _stream_via_http_bridge, which is what #1857's retry-http-bridge-rejected-anchor change and #1863 both do in different forms. I now think that is the wrong half of the problem to attack first, and that it carries exactly the fork risk you and I concluded was disqualifying on #1735 / #1736: upstream denying the anchor proves the second attempt created no child, but says nothing about whether the first attempt completed server-side, so an anchor-free resend can fork against it.

Clearing the anchor has no such problem. A proxy-injected anchor that upstream explicitly denies has no legitimate reader, so invalidating it on the first denial (not the seventh) costs nothing, and the client's next turn then dispatches with its own full history, which is the client's own replay rather than a server-side one.

I am going to try that shape against my host and will report numbers either way. Two changes, both small: clear durable continuity when a not-found names an anchor the proxy injected, at upstream_events.py:2278-2290 where the flag is already in hand, and stop masking the classifier on the bridge path so this is legible in logs. Happy to be told this is already covered by #1857, which does invalidate the anchor in both carriers as part of a much larger change.