Observation found while measuring for #8845. Unassigned. Not a claim. No behaviour is wrong on main today — filing so the narrowness is on the record rather than rediscovered.
Measured on origin/main @ 8664a2c.
What I found
scripts/check-durability-degradation-log-level.mjs, loggerLevel():
if(!receiverName)returnundefined;return/^(logger|log|console)$/i.test(receiverName) ? level : undefined;
The level vocabulary (error/warn/info/…) is matched against the method name, but the receiver must be spelled logger, log, or console. A logger reached through any other name is not a log as far as this file is concerned.
This is shared by both rules in the file, deliberately (collectLoggedLevels' header says so) — so the narrowness applies to the log-level rule's "how loud?" question and the read-seam rule's "did it say anything at all?" exemption at once.
The live example
packages/objectql/src/integrity/dangling-reference-audit.ts:547 — a catch that is careful and explicit about reporting:
report.unreadableObjects.push(name);port.warn?.('[integrity] dangling-reference audit could not list an object',{object: name,error: (errasError)?.message??String(err),});The receiver is port (the audit's injected dependency bundle), so collectLoggedLevels returns an empty array and my census classified this seam as silent. It is not silent; it is one of the better-written seams in the scan roots.
Why it has cost nothing yet
The read-seam rule only consults the log exemption after it has found an invented answer, and this seam invents none — so the misclassification never reaches a verdict. It is latent, not active.
Why it is still worth recording
The direction of the error is the unsafe one for the read-seam rule specifically: a genuinely loud catch reads as silent, so if such a seam ever also returns an empty value it goes red for the wrong reason, and the message will tell the author to "say something" next to a line that already does. The author's cheapest response is a baseline entry, on a shrink-only ledger.
Whether to widen it is a real judgement call, not an obvious yes: the receiver vocabulary is doing the same work DURABILITY_CRITICAL_CALLEES does elsewhere in the file — keeping a generic method name (warn) from matching anything that happens to spell it. Options I can see, none of them free:
- leave it, and note the narrowness in the header next to the other honest limitations;
- follow a same-file injected-logger parameter the way the file already follows same-file helper functions;
- declare additional receiver names explicitly, which is a second vocabulary to keep from going stale — the file's staleness checks exist because of exactly that.
My weak preference is (1) plus a header note, on the grounds that the file's existing answer to "my reporter has an unusual shape" is to follow a same-file helper, and (2) is the version of that which needs no new declared names.
Related
Observation found while measuring for #8845. Unassigned. Not a claim. No behaviour is wrong on
maintoday — filing so the narrowness is on the record rather than rediscovered.Measured on
origin/main@8664a2c.What I found
scripts/check-durability-degradation-log-level.mjs,loggerLevel():The level vocabulary (
error/warn/info/…) is matched against the method name, but the receiver must be spelledlogger,log, orconsole. A logger reached through any other name is not a log as far as this file is concerned.This is shared by both rules in the file, deliberately (
collectLoggedLevels' header says so) — so the narrowness applies to the log-level rule's "how loud?" question and the read-seam rule's "did it say anything at all?" exemption at once.The live example
packages/objectql/src/integrity/dangling-reference-audit.ts:547— a catch that is careful and explicit about reporting:The receiver is
port(the audit's injected dependency bundle), socollectLoggedLevelsreturns an empty array and my census classified this seam as silent. It is not silent; it is one of the better-written seams in the scan roots.Why it has cost nothing yet
The read-seam rule only consults the log exemption after it has found an invented answer, and this seam invents none — so the misclassification never reaches a verdict. It is latent, not active.
Why it is still worth recording
The direction of the error is the unsafe one for the read-seam rule specifically: a genuinely loud catch reads as silent, so if such a seam ever also returns an empty value it goes red for the wrong reason, and the message will tell the author to "say something" next to a line that already does. The author's cheapest response is a baseline entry, on a shrink-only ledger.
Whether to widen it is a real judgement call, not an obvious yes: the receiver vocabulary is doing the same work
DURABILITY_CRITICAL_CALLEESdoes elsewhere in the file — keeping a generic method name (warn) from matching anything that happens to spell it. Options I can see, none of them free:My weak preference is (1) plus a header note, on the grounds that the file's existing answer to "my reporter has an unusual shape" is to follow a same-file helper, and (2) is the version of that which needs no new declared names.
Related
return, so acatchthat degrades by FALLING THROUGH into an empty accumulator is structurally invisible #8845 — the measurement this came out of.check:durability-log-level结构性看不见「读接缝把故障答成空值」这一类 —— #4825 / #5108 全家都在闸门盲区里 #5186 / finding(devx): #5186 读接缝规则的「编造空答案」词表看不见「原样返回入参」这一形状 —— #6116 是实证样本 #6451 — the read-seam rule and its prior extension.