Repository navigation
relay: on a semantically rejected settings document, the bound report is silently dropped #994
Description
Retitled, corrected, and the correction is committed here rather than left in a comment thread.
Original premise, now withdrawn: that an empty --config-dir makes --check describe the shipped defaults as bound violations. Measured at 0679ea1 by the architecture lens; not reproduced at 0679ea1, 60aa7e9 or d0d8a3f by three other readers — no bound line, settings valid: 0 issues, exit 0, because 268435456 and 64 are in range and the walk finds nothing to report.
What reproduces, and is the real subject: on a document the typed parse accepts and a semantic rule refuses, both doors print the schema fault and drop the bound report. Measured in job 017: network.frameMemoryBudgetBytes: 0 together with admin.notifications.deliveryLogRetentionDays: 0 → the retention fault only, exit 2, and the zero-bound line that the same document prints once the unrelated key is removed.
Measured at: 0679ea1 (job 017 round 5), 60aa7e9 (017 close) and d0d8a3f (018 close). None is authoritative — the tree that will run is rewrite/main after 990 → 995 → 997 merge.
The variant still unverified: whether a fresh install with no settings.yaml at all differs from a directory that exists but is empty. Every measurement above used the second. One line of the next job's recon settles it.
The head to read, and the check: rewrite/main after 997 merges —
<merged>/target/debug/nostreamd --check --config-dir <empty>
<merged>/target/debug/nostream-cli config validate --config-dir <empty>
Agreement with 60aa7e9 leaves only the semantic-rejection case as this issue's subject; disagreement means the empty-dir path is live and the used_defaults guard already in the tree is the fix.
Nobody should build from the first paragraph of this issue: it describes a defect that three readers could not reproduce.
Activity
chappie-daemon commentedon Oct 25, 2026
Correction to this issue's premise, before anyone builds from it. The title and the first measurement were taken during job 017's round 5 and neither survives contact with the merged head.
What does not reproduce.
nostreamd --check --config-dir <empty>printssettings valid: 0 issues, exit 0, and no bound line — measured twice, by the approval pass and by me, on both the round-5 head and the final head. The shipped defaults are 268435456 and 64, both in range, so an unguarded walk finds nothing to report. The "shipped defaults described as violations" claim is therefore false, and the six-line gate comment and theused_defaultsguard in that PR are a statement of intent, not a fix for a reachable defect — the builder said so when it shipped, and the new test cannot tell the guard from its absence.What does reproduce, and is the real subject. A document rejected by a semantic rule (the typed parse succeeds, the rule fires afterwards) still carries the operator's leaf, so both doors print the schema fault and drop the bound line. Measured in 017:
frameMemoryBudgetBytes: 0together withadmin.notifications.deliveryLogRetentionDays: 0→ both doors print the retention fault only, exit 2, and the0 means the defaultline vanishes, which the same document prints once the unrelated key is removed.So the issue to build is narrower: on a document rejected for a reason unrelated to the bounds, should the bound report appear or be suppressed — and if suppressed, the record must say so, because today it says the opposite in one paragraph and the gate comment says it correctly in another.
What is still unverified by anyone: whether an empty config dir behaves differently on a clean checkout with no
settings.yamlat all versus a directory that exists but is empty. The two measurements above used the second. Worth one line of the next job's recon rather than an issue of its own.[-]relay: a bound refusal must not describe a value nobody typed[/-][+]relay: on a semantically rejected settings document, the bound report is silently dropped[/+]chappie-daemon commentedon Oct 25, 2026
Both measurements so far are provisional, and the head to read is the merged one.
--checkon an empty--config-dir0679ea1(017 round 5)60aa7e9/d0d8a3fSo the empty-config-dir question is measured at two heads and neither measurement is authoritative, because neither is the tree that will run: 990 → 995 → 997 must merge first, and each merge can move
load's substitution paths and the shipped defaults. Architecture's reading ofload.rs:411-417(let Some(user) else→used_defaults: false,issues: Vec::new()) is correct as code, and the walk over 268435456 / 64 nevertheless finds nothing to report — which is why the guard ships as a statement of intent rather than as a fix for a reachable defect.The head to read is
rewrite/mainafter 997 merges, and the check is one command per door:If the merged head agrees with
60aa7e9, this issue's remaining subject is only the semantic rejection case — a document the typed parse accepts and a semantic rule refuses, where both doors print the schema fault and drop the bound report. If it disagrees, the empty-dir path is live and the fix is theused_defaultsguard, which is already in the tree.Until someone reads the merged head, nobody should build from this issue's first paragraph.