Track upstream: Vale lint time is superlinear in single-block size, and no output is emitted until the run finishes #325

Activity

1. theCodeDrift

   added

   bugSomething isn't workingSomething isn't working

   CLIRelated to the taskless CLIRelated to the taskless CLI

   on Sep 9, 2026
2. theCodeDrift commented on Sep 9, 2026

   

   theCodeDrift

   on Sep 9, 2026

   MemberAuthor

   More actions

   Direction settled: this issue is the one we are betting on. #324 (batching) is closed in its favour.

   The position we are standing on until upstream moves:

   • VALE_MAX_FILE_BYTES (fix(cli): skip an oversized file instead of letting Vale time out on it #323) stays as the guard. It avoids the spend rather than spending and discarding it, and it is the only check cheap enough to run before spawning Vale.
   • We build no workaround for the all-or-nothing output. Batching would have made a timeout cost one batch instead of the whole run, and its entire value disappears if finding 2 here is fixed. Not worth carrying a workaround whose lifetime is bounded by a bug report we have already filed.
   • The size cap is knowingly a proxy for the wrong quantity, per finding 1: cost tracks single-block size, not file size. It over-fires on a well-formed 3 MB document (~4s, passes a 128 KB cap) and under-fires on a 512 KB single-block file (~2s, may sit beneath it). Accepted, because measuring block structure means reading every candidate, which costs more than the guard saves.

   Either upstream fix changes what we do here:

   • Incremental output (finding 2) removes the reason batching ever existed, and makes a caller-side timeout able to preserve findings.
   • Linear block cost (finding 1) lets VALE_MAX_FILE_BYTES rise substantially or disappear.

   A "won't fix" upstream is the trigger to reopen #324, not a reason to start it now.

   Reproduction repo, with the vale binary pinned via npm and npm run bug:reproduce: https://github.com/thecodedrift/reproduction_vale_blocks
3. theCodeDrift

   added a commit that references this issue on Sep 20, 2026

   docs: mark resolved as of Vale 3.21.0 and record the new measurements

   ...

   c788cb9
4. theCodeDrift commented on Sep 20, 2026

   

   theCodeDrift

   on Sep 20, 2026

   MemberAuthor

   More actions

   Verified with @taskless/vale-*@3.21.0-20260915061224: the 3 MB single-block fixture drops from ~81 s to ~230 ms and now matches the many-block file (~270 ms), with identical alert counts. Scaling a single block to 25 MB gives ~1.8 s, linear in size. Vale still emits nothing until the whole run finishes, but with no slow block for a timeout to hit that is no longer causing lost output; treating this as fixed for Vale ≥ 3.21 and archiving the repro repo.
5. theCodeDrift

   closed this as completedon Sep 20, 2026
6. theCodeDrift

   added 2 commits that reference this issue on Sep 21, 2026

   fix(vale): drop the 128 KB file-size guard

   ...

   3b3666f

   fix(vale): drop the 128 KB file-size guard

   ...

   b2e2662