link_payload_scaling_e2e's per-link ceiling grades the TEMP DIRECTORY'S LENGTH — 59 tokens on /tmp, 80 on a long path, 63 on the Windows runner #252

Closed
opened 2026-09-10 07:52:04 +02:00 by buildagent · 1 comment
Member

Found by the first real native-Windows verdict since 1d3228e. Run 726 on bd1c4e2
failed after 43 minutes with exactly one failing test in the entire suite:

crates\mcp-server\tests\link_payload_scaling_e2e.rs:259:13
one_link_costs_a_bounded_and_measured_number_of_tokens
HEADROOM ... per link (unavailable arm): 63 of 80 tokens (78.75% consumed),
17 left, reserve 19 — INTO THE RESERVE

The bound is a function of $TMPDIR

per_link is (t4 − t1) / 3 over serialized project_overview bodies. Every
once-per-response term cancels — but LinkedProjectSummary::path is an ABSOLUTE path
that appears once per link, so it does not cancel. The measurement therefore carries
one full temp-directory path per link.

Measured on ONE machine, changing NOTHING but TMPDIR:

TMPDIR length per-link verdict
/tmp 4 59 OK, 21 left against a reserve of 19
…/AppData/Local/Temp-longer-like-a-windows-runner 86 80 100% consumed, 0 left
native Windows runner — 63 17 left, INTO THE RESERVE

Linux passed by 2 tokens and Windows failed by 2. The 4-token gap is the runner's longer
temp root plus JSON escaping every \ as \\.

This is the file's own stated error class

The module doc names #160 §0 — "the gate's verdict was decided by which machine ran
it"
— as the mistake it exists not to make, and workspace_with_unavailable_links fixes
the width of every link NAME and DESCRIPTION for exactly that reason:

Names are FIXED-WIDTH (lnk00, lnk01, …) and so are the descriptions. A per-link
cost measured over names of different lengths would move with the fixture rather than
with the product.

path is the one per-link field that guard does not cover.

Fix

Normalise every link's path to a fixed-width placeholder before estimating, so the
ceiling grades which fields the product puts on a link — a product property — and not
how long the deployment's paths are, which is the deployment's.

Plus an anti-vacuity arm that keeps it honest: blanking one field only removes the
environment if that field was the ONLY per-link carrier of the root. The temp directory's
basename is random per run and cannot occur by accident, so the assertion is that no
remaining per-link field contains it.

After the fix the measurement is byte-identical across both environments — 60 per link,
1928/2108, on a 4-character TMPDIR and an 86-character one alike.

Mutations, run

  • Normalise the WRONG field (name instead of path) → RED on the anti-vacuity arm:
    a per-link field OTHER than 'path' still carries the workspace root (.tmpP0IX1h),
    printing the offending link.
  • Drop the normalisation entirely and run under the long TMPDIR → RED at 80/80,
    reproducing the Windows failure on Linux.
  • Restored from snapshot, md5 verified, all three tests in the file green.

Note on the remaining headroom

At 60 of 80 with a reserve of 19 there is exactly 1 token of true slack. That is the
#235 mechanism working as designed — it will fire before anything breaks — but the next
per-link field will trip it, and the right response then is to attribute and re-record,
not to widen. The ceiling was NOT moved as part of this fix; only the contamination was
removed, which happens to read 60 rather than 59 because the fixed-width placeholder is
slightly longer than a short real path.

Found by the first real native-Windows verdict since `1d3228e`. Run **726** on `bd1c4e2` failed after 43 minutes with **exactly one** failing test in the entire suite: ``` crates\mcp-server\tests\link_payload_scaling_e2e.rs:259:13 one_link_costs_a_bounded_and_measured_number_of_tokens HEADROOM ... per link (unavailable arm): 63 of 80 tokens (78.75% consumed), 17 left, reserve 19 — INTO THE RESERVE ``` ## The bound is a function of `$TMPDIR` `per_link` is `(t4 − t1) / 3` over serialized `project_overview` bodies. Every once-per-response term cancels — but `LinkedProjectSummary::path` is an ABSOLUTE path that appears **once per link**, so it does not cancel. The measurement therefore carries one full temp-directory path per link. Measured on ONE machine, changing NOTHING but `TMPDIR`: | `TMPDIR` | length | per-link | verdict | |---|---:|---:|---| | `/tmp` | 4 | **59** | OK, 21 left against a reserve of 19 | | `…/AppData/Local/Temp-longer-like-a-windows-runner` | 86 | **80** | 100% consumed, 0 left | | native Windows runner | — | **63** | 17 left, INTO THE RESERVE | Linux passed by 2 tokens and Windows failed by 2. The 4-token gap is the runner's longer temp root plus JSON escaping every `\` as `\\`. ## This is the file's own stated error class The module doc names #160 §0 — *"the gate's verdict was decided by which machine ran it"* — as the mistake it exists not to make, and `workspace_with_unavailable_links` fixes the width of every link NAME and DESCRIPTION for exactly that reason: > Names are FIXED-WIDTH (`lnk00`, `lnk01`, …) and so are the descriptions. A per-link > cost measured over names of different lengths would move with the fixture rather than > with the product. `path` is the one per-link field that guard does not cover. ## Fix Normalise every link's `path` to a fixed-width placeholder before estimating, so the ceiling grades **which fields the product puts on a link** — a product property — and not how long the deployment's paths are, which is the deployment's. Plus an anti-vacuity arm that keeps it honest: blanking one field only removes the environment if that field was the ONLY per-link carrier of the root. The temp directory's basename is random per run and cannot occur by accident, so the assertion is that no remaining per-link field contains it. After the fix the measurement is byte-identical across both environments — 60 per link, `1928`/`2108`, on a 4-character `TMPDIR` and an 86-character one alike. ## Mutations, run * Normalise the WRONG field (`name` instead of `path`) → RED on the anti-vacuity arm: `a per-link field OTHER than 'path' still carries the workspace root (.tmpP0IX1h)`, printing the offending link. * Drop the normalisation entirely and run under the long `TMPDIR` → RED at 80/80, reproducing the Windows failure on Linux. * Restored from snapshot, md5 verified, all three tests in the file green. ## Note on the remaining headroom At 60 of 80 with a reserve of 19 there is exactly **1 token** of true slack. That is the #235 mechanism working as designed — it will fire before anything breaks — but the next per-link field will trip it, and the right response then is to attribute and re-record, not to widen. The ceiling was NOT moved as part of this fix; only the contamination was removed, which happens to read 60 rather than 59 because the fixed-width placeholder is slightly longer than a short real path.
Author
Member

Fixed in 5131654, and confirmed on the native runner rather than only locally:

job    = 'fmt + clippy + build + test (windows)'
sha    = 5131654
status = success
duration = 43:10

43 minutes matches run 726's length, so the suite ran in full rather than short-circuiting — this is a real verdict, not an absent one. It is the first green native-Windows result on master since 1d3228e.

The fix normalises each link's path to a fixed-width placeholder before the payload is measured, with an anti-vacuity arm asserting no OTHER per-link field carries the workspace root (the temp directory's basename is random per run, so it cannot match by accident). After it the measurement is byte-identical across an 82-character TMPDIR swing — 60 per link, 1928/2108, on both a 4-character and an 86-character temp root, where it previously read 59 and 80.

The ceiling itself was not moved; only the contamination was removed. It reads 60 rather than 59 because the fixed-width placeholder is slightly longer than a short real path, which leaves 1 token of true slack above the reserve. The next per-link field will trip #235's reserve, and the right response then is to attribute and re-record rather than widen.

Filed alongside as #253: the same class of "the gate measures the machine" in claim_domain_scale, where a wall-clock ratio failed at load 37.9 and passes at load 3.0.

Fixed in `5131654`, and **confirmed on the native runner** rather than only locally: ``` job = 'fmt + clippy + build + test (windows)' sha = 5131654 status = success duration = 43:10 ``` 43 minutes matches run 726's length, so the suite ran in full rather than short-circuiting — this is a real verdict, not an absent one. It is the first green native-Windows result on master since `1d3228e`. The fix normalises each link's `path` to a fixed-width placeholder before the payload is measured, with an anti-vacuity arm asserting no OTHER per-link field carries the workspace root (the temp directory's basename is random per run, so it cannot match by accident). After it the measurement is byte-identical across an 82-character `TMPDIR` swing — 60 per link, `1928`/`2108`, on both a 4-character and an 86-character temp root, where it previously read 59 and 80. The ceiling itself was not moved; only the contamination was removed. It reads 60 rather than 59 because the fixed-width placeholder is slightly longer than a short real path, which leaves 1 token of true slack above the reserve. The next per-link field will trip #235's reserve, and the right response then is to attribute and re-record rather than widen. Filed alongside as #253: the same class of "the gate measures the machine" in `claim_domain_scale`, where a wall-clock ratio failed at load 37.9 and passes at load 3.0.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
h-dv/code-index#252
No description provided.