0.11.2 added VALE_MAX_FILE_BYTES (128KB) so one oversized file could not consume VALE_TIMEOUT_MS for the whole run. That guard was written against the Vale 3.20.0 binary, where lint time was quadratic in single-file size (80KB 0.3s, 160KB 0.9s, 320KB 3.5s, 640KB 14s, 1MB 48s).
The same release moved the vendored Vale to 3.21.0, which resolves the large single-block behavior upstream. Reference repo with the timing data: https://github.com/thecodedrift/reproduction_vale_blocks.
For the next patch:
- Re-measure the reproduction repo against the 3.21.0 binary and record the numbers in the changeset.
- Remove the preemptive size exclusion and the
notices entry it emits, or raise the bound to something a real document never hits if some superlinear behavior remains.
- Keep the per-file retry from the front-matter fix; that one is independent of file size.
- Drop the corresponding paragraph from the
update ledger's 0.11.2 section if it mentions the guard.
Jakob, 2026-09-20: "Taskless 0.11.2 is on vale 3.21 and so the restriction should be removed in the next patch release."
0.11.2 added
VALE_MAX_FILE_BYTES(128KB) so one oversized file could not consumeVALE_TIMEOUT_MSfor the whole run. That guard was written against the Vale 3.20.0 binary, where lint time was quadratic in single-file size (80KB 0.3s, 160KB 0.9s, 320KB 3.5s, 640KB 14s, 1MB 48s).The same release moved the vendored Vale to 3.21.0, which resolves the large single-block behavior upstream. Reference repo with the timing data: https://github.com/thecodedrift/reproduction_vale_blocks.
For the next patch:
noticesentry it emits, or raise the bound to something a real document never hits if some superlinear behavior remains.updateledger's 0.11.2 section if it mentions the guard.Jakob, 2026-09-20: "Taskless 0.11.2 is on vale 3.21 and so the restriction should be removed in the next patch release."