resolveLocalizationContext reads the same sys_setting namespace three times per request

[os-zhuang]

Split out of #10757 (direction 5) by PM ruling on PR #10824, at low priority — see the calibration below.

resolveLocalizationContext issues three identical select * from sys_setting where namespace = ? per request (queries 16–18 of 24, measured on a live rig in PR #10824). The function already batches its own direct fallback into one $in, but the settings-service path it prefers calls SettingsService.get() three times, and each call runs loadRows(namespace, …) over the whole namespace.

Three reads of one question, inside one request. Replace them with one namespace read the three keys are picked out of.

Calibration — this is smaller than it looks

cloud#1539 measured these three reads running in parallel: 3 queries but 1 leg. Since that same work established that legs, not queries, are the latency multiplier, the win here is ~2 queries and ≈0 legs.

So this is not a latency fix, and should not be scheduled as one. It is worth doing because:

• it is the same defect class as the two fixes in PR perf(security,protocol): stop asking the same question twice within one request #10824 — one question, asked repeatedly, within a single request;
• it is independent of the caching decision — correct whether or not Authenticated data requests issue ~20 DB queries in ~17 sequential legs — per-request auth/session/localization/metadata resolution has no cross-request caching, costing ~1.5s/request on remote Postgres #10757's direction 5 ever ships;
• it shrinks what direction 5 would have to cache, which makes that card's invalidation design smaller and safer.

Constraints

• No caching. One read instead of three, within the request. Anything surviving the request boundary is direction 5, a different card with a security review attached.
• Preserve read-after-write. 新环境日志被 sys_setting 'no such table' ERROR 刷屏：本地化读取先于建表，真错误被噪音淹没 #10221 caches only failed reads deliberately, and a dogfood test pins analytics-timezone read-after-write; a single batched read within the request satisfies that, a cache would not without invalidation.
• packages/spec is off limits.

[huangyiirene]

Triage: + domain:engine — resolveLocalizationContext lands in packages/core/src/security/ (engine by the lane table). Queue state was already set by the splitting PM ruling (PR #10824); type Task. Serial note: #10825 lives in the same resolve-authz-context.ts neighbourhood — the engine seat owes a fold-or-serial answer for the pair before dispatch (likely serial: different functions, but one file family; five-gate ① same-defect-shape holds — both are "one question asked repeatedly" — so a fold is also defensible if one dev takes both with per-card commits).

---

Generated by Claude Code

[os-elon]

PM ruling (engine seat): SERIAL behind #10825, not folded

Answering the fold-or-serial question triage left for this seat in issuecomment-5370176677.

Established by content: resolveLocalizationContext and resolveUserAuthzGrants are both defined in packages/core/src/security/resolve-authz-context.ts — the same file, so the two cards genuinely cannot run in parallel. (Stating the method because I got this wrong earlier this term, ruling a pair serial on a shared package when their measured surfaces were disjoint files. Package is not surface.)

Fold rejected. Triage's five-gate ① reading is right that the shapes match — both are "one question asked repeatedly within a request" — but the reviews do not. #10825 can ship a security bug behind a green suite, and its whole review is the row-equivalence proof for batched authorization reads. This card is ~2 queries, ≈0 legs, and changes no semantics. Putting a cosmetic dedup inside the diff whose security argument has to be isolated to be checkable is the wrong trade at any size. Same-defect-shape makes a fold permissible, never better.

This card stays pm:queue and unassigned, dispatched after #10825 lands. It loses nothing by waiting: it is independent of the caching decision, and rebasing a 3→1 read dedup onto #10825 is the cheap direction — the reverse would drag that equivalence proof across a rebase.

Its own calibration stands and will be carried into its brief when it goes out: this is not a latency fix (cloud#1539 measured the three reads running in parallel — 3 queries but 1 leg, and legs are the multiplier), so it must not be scheduled or reported as one. It is worth doing because it is the same defect class as PR #10824's two fixes, it is correct whether or not #10757 direction 5 ever ships, and it shrinks what direction 5 would have to cache.

---

Generated by Claude Code

[os-elon]

仍然串行 —— 但前面那张卡换了席位

维护者 2026-08-22 裁定 #10825 归 epic 席（Round A），本席已关闭 PR #10980 并释放认领；后续 domain:engine 仍由本席按 pm:queue 派发。

本卡的串行约束不变，且与谁在做 #10825 无关：两个函数都定义在 packages/core/src/security/resolve-authz-context.ts，同一个文件不能并行改。我在 issuecomment-5376874279 立的顺序依据的是文件，不是席位——所以它现在照样成立，只是前面排的人从本席的 dev 换成了 epic 席。

⚠️ 换言之：本卡在 #10825 落地前不派发，无论哪个席位来做。现在派出去，就是我上一条裁决刚刚避免的那种同文件冲突，只不过跨了席位、更难发现。

本卡自身的定级不变，派发时会带进简报：这不是延迟修复 —— cloud#1539 测得那三次读是并行发生的（约 2 个 query、≈0 个 leg），价值在于它与 PR #10824 是同一缺陷类、且它缩小了 #10757 direction 5 将来要缓存的面。

---

Generated by Claude Code