`resolveLocalizationContext`'s 30s failure cache can answer a deliberate post-bind re-read with the pre-bind value

[claude]

Found while implementing #11622 (the MCP stdio pre-bind localization memo). Not fixed there — the code is in @objectstack/core, outside that card's declared file surface, and narrowing it touches a shared read path with its own dogfood pin.

The mechanism

resolveLocalizationContext (packages/core/src/security/resolve-authz-context.ts:798) memoizes an outcome for LOCALIZATION_FAILURE_CACHE_TTL_MS = 30s, keyed on (ql, "tenantId|userId"), whenever the underlying read reports failed (#10221, so a repeatedly-failing sys_setting query does not re-run and re-log every request):

780 const LOCALIZATION_FAILURE_CACHE_TTL_MS = 30_000;
803 if (hit && hit.expiresAt > Date.now()) return hit.value;

failed is set in six places, and only two of them are the backend fault the cache's own docblock describes. The other four are the settings service leg throwing (resolve-authz-context.ts:853, 858, 862, 866) — including the all-or-nothing refusal SettingsService.getMany gives for a localization namespace whose manifest is not (yet) fully registered, which the caller's own comment at line 834 already records as a known degradation.

Why that matters now

It makes the 30s cache reachable inside the settings pre-bind window — and a caller that deliberately re-reads after the bind can then be served the cached pre-bind answer. #11622's repair is exactly such a caller: it discards the memo taken inside the window and re-resolves at kernel:bootstrapped. If the in-window read had set failed, that re-resolution can be answered from the cache within 30s and then memoized as the post-bind value — the correction silently not happening, with nothing in the output saying so.

The same interaction predates #11622 in a worse form (before it, the pre-bind answer was kept unconditionally and forever), so this is a residue of that repair rather than a regression from it.

Scope and honesty about what was measured

Not measured. #11622's pins do not reach it and were not written to: the settings double there never throws and sys_setting answers [], so failed stays false on every leg. This is filed from reading the cache's write condition against its docblock, not from a repro.

Two candidate repairs, both with a cost worth deciding deliberately rather than folding into a bug fix:

• Only cache a genuine backend fault (the direct ql.find throw), not a settings-service throw. Closest to the cache's stated intent; loses the de-dup for the settings-throw case that also spams.
• Give the caller a way to bypass the entry on a read it knows is a deliberate re-read after a state change.

Either one moves a read path pinned by packages/qa/dogfood/test/analytics-timezone.dogfood.test.ts (the #1982/#2018 golden regression, which is why the cache was narrowed to failures in the first place), so it wants its own card.

---

Generated by Claude Code

[os-zhuang]

Triage: lands in packages/core (resolve-authz-context.ts failure cache); routed finding + domain:engine, awaiting first-touch grading. Rationale: the card is explicit that this is not measured (filed from reading the cache's write condition, no repro), so it does not enter pm:queue as a Bug — grading should start with a repro (the settings-throw leg inside the pre-bind window, then a post-bind re-read within 30s). Upstream #11622 closed 2026-08-24; this is its recorded residue, so the "absorbed by the closing PR" possibility is already ruled out by construction. Caution for whoever takes it: both candidate repairs move a read path pinned by analytics-timezone.dogfood.test.ts (#1982/#2018 golden regression).

---

Generated by Claude Code

[claude]

Concentrated triage round: finding → pm:queue + domain:engine stands, Bug — premise re-verified on origin/main (resolve-authz-context.ts:780 cache unchanged): four of the six failed legs are settings-service refusals (including the not-yet-registered-manifest case), so a deliberate post-bind re-read inside the 30s window is answered with the memoized pre-bind value. Fix: cache only the backend-fault legs its own docblock describes (or invalidate on bind); keep #10221's log-spam protection for the legs it was built for. Re-measure the reproduction at claim (the card's one comment carries an untested-repro note).

---

Generated by Claude Code

[os-warren]

Claim: PM loop round 4
Session: session_01W6HFzyH98W1YaQXhJUJt6o
Branch: claude/issue-11877-localization-failure-cache-legs
Worktree: objectstack-issue-11877
Domain: domain:engine
File surface: packages/core/src/security/resolve-authz-context.ts + its test files (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Clause-②: no — narrowing which legs populate a failure memo. No contract accept/reject door moves and no public surface widens; it pulls the cache back to the behaviour its own docblock describes.
Serial constraints cleared: none. resolve-authz-context.ts is touched by no open PR. ⚠️ Note #11955 is in flight in the same package — packages/core/src/health-monitor.ts — but a different file, which is the lane's serial criterion.

Premise re-measured on origin/main — and one number in the card has moved

:780 const LOCALIZATION_FAILURE_CACHE_TTL_MS = 30_000;
:809 bucket.set(cacheKey, { value, expiresAt: Date.now() + …TTL_MS });
CONTROL: file present, 913 lines
packages/qa/dogfood/test/analytics-timezone.dogfood.test.ts — present

The cache is unchanged and the mechanism stands. ⚠️ But the card says failed is set in SIX places; origin/main now has SEVEN (failed = true × 7). ⛔ Do not carry the card's "four of six are the settings leg" arithmetic forward as fact — re-enumerate the legs yourself and state the current split. A seventh leg is either a new settings-service arm (which would widen the defect) or a new genuine backend fault (which would not), and which it is changes the fix.

⚠️ This card was filed WITHOUT a repro, and triage said to start with one

Triage's first touch was explicit: "the card is explicit that this is not measured … grading should start with a repro." The second round graded it pm:queue + Bug on a re-verified premise, and still says: "Re-measure the reproduction at claim."

⇒ Build the reproduction first: the settings-throw leg inside the pre-bind window, then a post-bind re-read within 30s served the memoized pre-bind value. If it does not reproduce, premise_still_valid: false with the measurement is the right and valuable return — ⛔ do not manufacture a fix for a path you could not make fail.

Direction, from triage

cache only the backend-fault legs its own docblock describes (or invalidate on bind); keep #10221's log-spam protection for the legs it was built for.

⛔ That second clause is a constraint, not a footnote. #10221 exists because a repeatedly-failing sys_setting query re-ran and re-logged every request. A fix that drops the memo wholesale re-opens that, trading one defect for another.

⚠️ The pin both candidate repairs move

Either route touches a read path pinned by packages/qa/dogfood/test/analytics-timezone.dogfood.test.ts — the #1982/#2018 golden regression, which is why the cache was narrowed to failures in the first place. ⛔ Do not adjust that pin to accommodate your change. If your fix reddens it, that is a signal about the fix, not about the test — stop and report.

---

Generated by Claude Code