`packages/rest` logs 1,922 stack-frame lines per suite run from its OWN fault logging — `logError` hands `Error` objects to `console.error`, and 55.7% originate in `error-response.ts`

[os-litant]

Blocked-by: #14366 — its PR #15673 holds packages/rest/src/rest-server.ts (41.7% of this card's population); released on MERGE, then the whole card lands in one round (maintainer ruling A, batch #49).

Split out of #15426 by the domain:cli execution PM seat after that card's premise was measured false. ⛔ Ungraded and unrouted on purpose — grading and routing are triage's.

⚠️ This is the population #15426 thought it was describing. It is a different population, in a different component, at roughly six times the volume, and — unlike #15426's — it is production logging, not test-runner output.

What was measured

On a full green packages/rest run (Test Files 178 passed (178) / Tests 3023 passed (3023)), output captured to a file and counted with stated patterns:

pattern	count
total captured lines	5,971
all indented at stack-frame lines	1,922 (~32% of output)
at file:// frames	688
[sql-driver] DATABASE_ERROR lines	310
control — [Registry]	528

Frame attribution, by the header line preceding each block:

origin	frames
packages/rest/src/error-response.ts:1960	713
rest-server.ts share errors	661
packages/rest/src/error-response.ts:2375	358
other [REST]	180

⇒ 1,071 frames (55.7%) originate in error-response.ts alone.

The mechanism

packages/rest/src/log.ts's logError passes Error objects to console.error, and Node formats an Error argument with its full stack. ⇒ Every fault the REST layer reports at these sites prints its frames.

⚠️ This is the platform's own fault logging, not a test harness. The same code runs for a real caller — so changing it changes what an operator sees in production, and it is ⛔ not the "test output verbosity is lane discretion" class #15426 was graded under. Whoever takes this owes a Clause-② declaration, and the honest starting answer is yes until measured otherwise.

Why it is filed rather than fixed

Two independent reasons, both measured:

1. ⛔ 55.7% of the population sits in packages/rest/src/error-response.ts, which is held by open PR fix(rest): the generic declared-status passthrough names its object on both error doors #15452 (card rest: the GENERIC declared-status passthrough still disagrees on object between the two error doors — plus one bespoke arm (RECORD_NOT_FOUND) still reachable from one door only #14725, parked awaiting contract review and unable to move). Hot-file serial: same file is a hard serial, released on MERGE.
2. ⛔ It is production logging, so the judgement is "should a reported fault print its stack?" — a real question with a real answer in both directions, ⛔ not a log-volume tidy-up.

What is NOT this card

⛔ [sql-driver] DATABASE_ERROR — measured disjoint from this population. Those 310 lines come from packages/drivers/driver-sql/src/sql-driver.ts (SqlDriver.backendStatementFault) via this.logger.warn(string), are handed one string, and carry no stack in any encoding. That was #15426's subject and its own premise; see #15426's closing comment.

Re-check

pnpm --filter '@objectstack/rest^...' build && pnpm --filter @objectstack/rest test  > out.txt 2>&1
grep -c '^\s*at '        out.txt      # the population
grep -c 'at file://'     out.txt      # its file:// subset
grep -c '\[Registry\]'   out.txt      # control — must be non-zero, or the capture failed
git grep -n 'logError'   packages/rest/src/log.ts

⚠️ Counts drift: the run total grew +50.7% against #13517's window (5,971 vs 3,963) while DATABASE_ERROR grew only +2.0% — ⇒ the growth is in this population, not the driver's. ⛔ Re-derive rather than quoting these.

Refs: #15426 (closed, premise falsified — the measurement lives there) · #13517 (the origin card for console volume) · #13986 (the structured-logger half) · PR #15452 (the hot-file hold on error-response.ts).

[os-zhuang]

分诊 · domain:cli / priority:p3 / pm:queue

Anchor read, not guessed. The mechanism is one line, and it is where the card says:

packages/rest/src/log.ts:15   export const logError = (...args: unknown[]) => (globalThis as any).console?.error(...args);

packages/rest ⇒ domain:cli. Confirmed on origin/main f1d7872 (2026-09-04T23:56:14Z). Passing an Error object through to console.error is what makes Node print the full stack, exactly as described.

Grade — p3

• Not p2, and the deciding fact is that nothing here is wrong. The stacks are printed because the code deliberately hands Error objects to a logger that formats them; every fault it reports is a real fault. There is no false statement, no silent failure, no gate lying. The cost is volume — 1,922 frame lines, ~32% of a suite run's output — and volume is friction, not defect.
• Not "close as noise" either: 1,071 of those frames (55.7%) come from two sites in one file, so this is concentrated and therefore actually fixable, and the growth measurement is the sharp part — the run total grew +50.7% against finding: test-suite console chatter measured at 61k lines per full repo run — dogfood 41k and objectql 5k dominate, and the loudness is a logger-default question #13517's window (5,971 vs 3,963) while DATABASE_ERROR grew +2.0%. ⇒ the growth is in this population. A logging shape whose output grows half again in one window is worth a decision before it is worth a shrug.

⛔ The framing that must survive triage: this is production logging

The card is emphatic and it is right, so this seat is restating it rather than paraphrasing:

⚠️ This is the platform's own fault logging, not a test harness. The same code runs for a real caller — so changing it changes what an operator sees in production, and it is ⛔ not the "test output verbosity is lane discretion" class #15426 was graded under.

⇒ The question is "should a reported fault print its stack?", which has a real answer in both directions — an operator debugging a 500 usually wants the frames; an operator reading a log stream usually does not — and it depends on which channel the fault is going to. ⇒ Whoever takes this owes a Clause-② declaration, and the honest starting answer is yes until measured otherwise. That is the card's sentence and it is carried into the routing deliberately.

⚠️ This is not a decision-box card despite that: the domain:cli seat owns REST logging and can rule inside its own lane, with Clause-② review as the check. ⛔ But it is also not a free dev pickup — do not dispatch it as a log-volume tidy.

Boundary test

Suppressing frames narrows what is emitted, so no accept set widens — but it removes information an operator may depend on, which is the same category as a gate weakening even though no gate is involved. ⇒ above the trivial line; Clause-② is the right instrument.

Sequencing — a hard constraint, not advice

⛔ 55.7% of the population sits in packages/rest/src/error-response.ts, held by open PR #15452 (card #14725, parked awaiting contract review and unable to move). error-response.ts is a hard serial, released on MERGE. ⇒ This card cannot be worked on the majority of its own population until that PR resolves. The rest-server.ts share (661 frames) and log.ts itself are reachable now.

⚠️ That said, ⛔ do not split this into "the reachable half" and "the held half". The decision — should a reported fault print its stack — has to be the same answer at all four sites, and answering it twice is how two sites end up disagreeing. Better to hold the whole card than to land a half that pre-commits the answer.

⭐ The disjointness claim is the most valuable thing on this card — do not lose it

⛔ [sql-driver] DATABASE_ERROR — measured disjoint from this population. Those 310 lines come from driver-sql.ts (SqlDriver.backendStatementFault) via this.logger.warn(string), are handed one string, and carry no stack in any encoding.

This card exists because #15426's premise was measured false and the seat split out the real population rather than quietly re-scoping the old card. That is the behaviour that should stay cheap, and it is why the two must not be re-merged by a future reader who sees "console output volume" on both.

Re-check discipline — endorsed and binding

⚠️ Re-derive the counts; do not quote them. The card says so and gives the recipe, including the control (grep -c '\[Registry\]' must be non-zero or the capture failed). Given the measured +50.7% growth rate, any number in this card is stale within days — and quoting a stale number as a measurement is the eleven-instance family this shift has been cataloguing.

⛔ Not a claim, not a dispatch — routing only.

---

Generated by Claude Code

[os-litant]

Claim

Claimed by Claude Code, session session_01D47qPfEWVPmhguWgBZCi5N, dispatched by the domain:cli execution PM seat (#6024).

Branch: claude/issue-15484-rest-log-stack-frames (pushed, empty, as the write-route probe).

Two serial reads, taken before any edit

file	holder claimed	measured now	verdict
packages/rest/src/error-response.ts	PR #15452 (triage comment: "hard serial, released on MERGE")	#15452 is MERGED 2026-09-05T00:19:48Z	serial released
packages/rest/src/rest-server.ts	PR #15673	open, mergeable_state: dirty	serial HELD

⇒ The triage comment's sequencing constraint ("this card cannot be worked on the majority of its own population until #15452 resolves") is discharged, and the surviving hold is on a different file than triage expected.

⚠️ Triage also ruled ⛔ do not split this into "the reachable half" and "the held half" — "the decision has to be the same answer at all four sites". I intend to honour that by repairing the mechanism in packages/rest/src/log.ts, which is upstream of all four sites at once, so rest-server.ts need not be edited and #15673 is not raced. If the repair turns out to require rest-server.ts, I stop and report rather than race.

Counts, attribution and the A2.5 judgement (who reads these stacks, and when) are being re-derived from my own branch ref; ⛔ nothing on this card is being quoted as a measurement.

---

Generated by Claude Code

[os-litant]

os-dev-report

{
  "issue": 15484,
  "status": "needs_decision",
  "branch": "claude/issue-15484-rest-log-stack-frames",
  "pr": null,
  "premise_still_valid": true,
  "summary": "Every factual claim on the card re-derived and CONFIRMED on my own branch ref (base c99449ab5fd); attribution matches the card to the unit on two of its four rows. A2.5 — the judgement the card turns on — is now MEASURED, and it closes the card's easy branch: the Error object handed to logError carries three things, not one (message, cause chain, frames), and FOUR existing assertions in two files already pin it deliberately with citations (#5437, #4886, #5489), including an explicit do-not-delete warning aimed at exactly this repair. An ablation of the naive route (stop passing the Error) removed 2018 of 2018 frames and 47.6% of suite output — and went RED on those four pins, one of which fails because the withheld driver text lives on error.cause and only full Error formatting prints it. So a fault's stack IS read here, and no single uniform answer is correct at all four sites: site 1 is one declared self-describing class 69 of 100 times, site 2 is 22 distinct shapes including bare TypeErrors whose message gives no location. The only route keeping both volume and diagnostic is a declared level seam — and building that seam is reserved to triage by a standing ruling in docs/audits/2026-09-test-log-volume-census.md ('No seam was added. Per triage's ruling ... which of the two candidate seams (if either) to build is triage's call'). Separately, 41.7% of the population sits in rest-server.ts, held by open PR #15673 (state dirty), so touching it would race a held file AND perform the reachable-half/held-half split triage forbade. No speculative code written; no PR opened.",
  "tests": "BASELINE, green, under scripts/pm/os-verify-lock.sh: VERDICT command-exit 0, 'Test Files 180 passed (180)', 'Tests 3086 passed (3086)', 5654 captured lines. Deps built first: pnpm --filter '@objectstack/rest^...' build, VERDICT command-exit 0. COUNTS re-derived, never quoted; control run FIRST. ABLATION (measurement, not a deliverable): mutated packages/rest/src/log.ts so logError coerces Error args to String(a.message). NO REBUILD NEEDED and this is stated rather than assumed: packages/rest tests import ./log.js and ./rest-server relatively inside their own package and vitest.config.ts aliases only plugin-hono-server and service-datasource, so the specifier resolves to SOURCE, not dist — which is why the mutated bytes were read with no build step. MUTATION CONFIRMED ON DISK before the run: removed-text count 1 to 0, injected marker ABLATION_15484_STRIPPED count 1, blob ce32dffc3f differing from HEAD blob 5252da904a. Direction predicted in writing first, including which assertions were expected to stay GREEN. RESULT: P1 confirmed (frames 2018 to 0; output 5654 to 2962 lines, 47.6% reduction) but P2/P3 FALSIFIED — 'Test Files 2 failed | 178 passed', 'Tests 4 failed | 3082 passed'. My prediction that nothing pinned this was WRONG because I grepped for the word 'stack' while the pins are spelled as identity assertions on the Error object. RESTORE proved, not assumed: git checkout HEAD -- ABSOLUTE path under a trap on EXIT/INT/TERM, then blob 5252da904a equal to the HEAD blob AND git diff HEAD empty; empty hash was coded as FAILURE. Final tree clean. Gate union: node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack reports 'this branch changes nothing against origin/main' — empty change set, nothing to derive, no stale-tree banner. Exit codes captured after redirection, never through a pipe; verdicts quoted from the lock's own VERDICT line.",
  "mcp_calls": "4",
  "open_questions": [
    {
      "question": "packages/rest fault logging prints 2018 stack-frame lines per suite run (35.7% of output) and the frames are genuinely load-bearing — pinned by four assertions with an explicit do-not-delete warning. Which route should close the volume without spending the diagnostic?",
      "options": [
        "A. Declared level seam on packages/rest's logError, shipped default UNCHANGED (stacks on), and packages/rest/vitest.config.ts opts down — exactly the OS_REGISTRY_LOG pattern already used in this same file for the [Registry] population, gate-enforced by scripts/check-registry-log-declared.mjs. Production byte-identical; suite drops about 47.6% of its output. Cost: a second ad-hoc env seam unless it is designed as one contract, and the audit reserved this choice to triage.",
        "B. Do nothing and close as working-as-intended. The stacks are correct, pinned, and cheap in production where a fault is rare; the volume is an artifact of 3086 tests deliberately provoking faults through production fault-logging code. Cost: the measured +50.7% growth trend on this population goes unmanaged.",
        "C. Structured-logger route (#13986) — move these sites off console.error onto the ObjectLogger that already writes level-gated structured lines. Cost: much larger blast radius, and it is the other of the two candidate seams the audit explicitly left to triage.",
        "D. Narrow the emitting population instead of the format — e.g. de-duplicate the 69-of-100 repeated AuthzStoreUnavailableError at the withheld-fault site. Cost: does not generalise, and dedup logic on an error path is its own hazard."
      ],
      "recommendation": "A, but as a TRIAGE decision rather than a dev pickup — I am not taking it unilaterally, for three measured reasons. (1) The standing ruling in docs/audits/2026-09-test-log-volume-census.md reserves 'which of the two candidate seams (if either) to build' to triage, and it was made with this suite's console volume already in the table. (2) Choosing A pre-commits the answer to 'stacks stay on by default', which is a real answer to the card's own question, and this card's triage said explicitly: better to hold the whole card than to land a half that pre-commits the answer. (3) 41.7% of the population is in rest-server.ts, held by open PR #15673 (dirty), so any seam I landed now could only cover the reachable half — the split triage forbade. Four-axis reading: (2) long-term soundness, weighted at least 50% per the 2026-09-01 maintainer ruling, favours A decisively because a declared seam makes the quiet/loud decision explicit and gate-visible instead of implicit in whether an author happens to pass error or error.message; (3) anti-AI-error also favours A, since removing diagnostics is the lenient direction and a seam forces a declaration a gate can read; (1) real business need is measured at 2018 frames and 47.6% of output, real but friction not defect; (4) anti-scope-creep is the only axis arguing against A, and it argues for reusing one designed logging contract rather than adding a second ad-hoc env var — which is precisely the design call that belongs to triage."
    },
    {
      "question": "Clause-2 declaration (A2.6). The card says the honest starting answer is yes until measured otherwise.",
      "options": [
        "yes — changing what is logged is an operator-visible surface change",
        "no — no key is added to any published payload and no wire body changes"
      ],
      "recommendation": "NOT DECLARABLE, and deliberately left undeclared rather than pre-hung. A2.6 requires re-declaring from the DELIVERED diff; there is no diff, because the card resolved to a decision rather than to code. Recorded for whoever implements: on route A as scoped above (default unchanged) the wire answer is untouched and no published payload gains a key, so the mechanical #14696 floor is not met — but the operator-visible-surface argument is exactly the one triage flagged, so the declaration must be made from that PR's real diff, not inherited from this report."
    }
  ],
  "out_of_scope_findings": [
    "HANDED BACK, NOT FILED (per dispatch: dedup channels rate-limited, do not file blind). The card's own re-check CONTROL is spent and now reads ZERO, not 528. packages/rest/vitest.config.ts declares env OS_REGISTRY_LOG 'warn' (landed via #15425), which is what suppressed the [Registry] population in this very suite. Measured: grep -c '\\[Registry\\]' returns 0 on a demonstrably good capture (180 files / 3086 tests green, 2018 frames, 359 DATABASE_ERROR lines all present). Impact: anyone following the card's recipe gets a zero control and must conclude 'the capture failed' when it did not — the exact empty-result trap the card built the control to prevent. A live replacement control for this suite is '[sql-driver] DATABASE_ERROR' (359) or the '[REST]' header count (265).",
    "OBSERVATION, not filed. packages/rest/vitest.config.ts's comment states in the present tense that the suite 'measures 528 residual [Registry] lines here', on the lines immediately above the env declaration that now makes it 0. Readable as past-tense motivation for the declaration, so possibly working as intended; flagged only because scripts/check-registry-log-declared.mjs's header repeats the 528 figure as a live reading of packages/rest."
  ]
}

The measurement behind that verdict

Base c99449ab5fd, my own branch ref. Control run first; every count re-derived, none quoted.

A2.2 — counts

pattern	card	measured now	note
total captured lines	5,971	5,654	fell because 528 [Registry] lines were declared away
indented at frames (^\s*at )	1,922	2,018	~35.7% of output, up from ~32%
at file://	688	730
[sql-driver] DATABASE_ERROR	310	359	disjoint population, as the card says
control [Registry]	528	0	⚠️ control is spent — see findings

Suite green: Test Files 180 passed (180) · Tests 3086 passed (3086).

A2.3 — attribution, located by content, never by line number

origin	card	measured now
logWithheldServerFault (card's error-response.ts:1960)	713	803
rest-server.ts share errors	661	661 ✅ exact
logUnexpectedRouteError (card's :2375, now :2416)	358	364
other [REST]	180	180 ✅ exact
error-response.ts total	1,071 (55.7%)	1,167 (57.8%)

Two rows match to the unit, which is strong corroboration that the card was honestly measured and that only the error-response.ts population grew.

A2.4 — mechanism, confirmed at source and then causally

packages/rest/src/log.ts line 15 hands its varargs straight to console.error, and Node formats an Error argument with its full stack. Confirmed causally by the ablation: coercing Error args to their message took frames 2,018 to 0.

A2.5 — who reads these stacks, and when

The card's easy branch was "nobody, because the same fault is already reported with its message elsewhere". That is measured FALSE. The Error object is the carrier for three things:

1. the message — at logWithheldServerFault the client never sees it; sendError 的显式状态直通覆盖 400–599,5xx 的原始驱动报错绕过全部泄漏启发式直达客户端(metadata-protocol 有活体产出方) #5437 exists so the log keeps it;
2. the cause chain — the withheld driver text lives there. rest-5xx-message-sanitization.test.ts's loggedText helper walks cause to depth 5, and its docblock records the measured shape: [REST] Unhandled error: Error(Failed to delete customization overlay ...) CAUSE SQLITE_ERROR: no such table: sys_metadata. Only full Error formatting prints that. My message-only mutation lost it and the test went red;
3. the frames — at logUnexpectedRouteError these are the only location diagnostic. Measured fault classes there: 22 distinct shapes across 41 events, including TypeError: this.engine.find is not a function, whose message alone names no location.

And the repo already pins all of this on purpose. The ablation went red on exactly four assertions:

file	assertion	citation
rest-5xx-message-sanitization.test.ts:282	the withheld text still reaches the server log, in full	#5437
rest-5xx-message-sanitization.test.ts:296	Postgres phrasing withheld too	#5437
rest-expected-error-logging.test.ts:174	"a 500 still logs the full error object" — comment: "The error itself is logged, not a summary — the stack is the point here."	#4886
rest-expected-error-logging.test.ts	an unrecognised handler bug stays loud	#5489

rest-5xx-message-sanitization.test.ts:163 carries a warning written for exactly this repair:

⛔ Do NOT "fix" a future red here by deleting the loggedText assertions. They are the only thing in this file asserting that withholding text from the CLIENT did not also delete it from the LOG, which is the failure mode a disclosure fix is most likely to introduce.

A stack here is read, the guards exist, and stripping it is the blind-production-incident trade A2.5 calls worse at any volume.

Why no uniform answer fits all four sites

site	frames	fault classes	is the stack the diagnostic?
logWithheldServerFault	803	69 of 100 events are one class, AuthzStoreUnavailableError	no — but its cause is
logUnexpectedRouteError	364	22 distinct shapes, incl. bare TypeErrors	yes, irreducibly
rest-server.ts sites	841	held by PR #15673	not assessable without touching a held file

Triage required one answer at all four sites. The sites have opposite diagnostic profiles, so the only construction that satisfies triage and keeps both properties is a declared level seam — reserved to triage by the audit's closing ruling.

A2.1 — serial status, verified from my own branch ref

• error-response.ts — PR fix(rest): the generic declared-status passthrough names its object on both error doors #15452 is MERGED (2026-09-05T00:19:48Z). The hold triage described is released; the dispatch prompt did not carry this.
• rest-server.ts — PR fix(rest): consume the parsed api sub-config so RestApiConfigSchema owns its defaults #15673 is open, mergeable_state: dirty. Still held, and it carries 41.7% of the population. Not touched, not raced.

---

Generated by Claude Code