v1.2.1

Fixed

Artifact preflight could stall a job for tens of minutes

The bundle-wasm-reference detector matched an unbounded character class before the .wasm literal:

/[^\s"'`\\)\]}>,;]+\.wasm\b/gi

That class excludes whitespace, quotes and brackets, but not base64 characters. A minified main.js that embeds a base64 payload — an inline WebAssembly module, font, image, or sourcemap — therefore contains one unbroken run of characters with no boundary in it. The engine began a match attempt at every offset inside that run, consumed to the end of the run, then backtracked across it looking for .wasm, giving quadratic behaviour.

On a real 2.9 MB plugin bundle holding a 568,136-character inline WebAssembly blob, that works out to roughly 3.6 × 10¹¹ backtracking steps — about 42 minutes of solid CPU with the Artifact preflight group open and no output written. Affected runs were being cancelled or hitting the job timeout, with nothing in the log to indicate why.

The detector now anchors on the .wasm literal and expands backwards to a path boundary, so there is no backtracking at all. The same bundle now completes in milliseconds and reports the same references.

Two things made this easy to hit and hard to diagnose:

• Any plugin bundling a large base64 payload was affected, whether or not it uses WebAssembly — the run of base64 characters is what triggers it, not the payload's contents.
• Artifact preflight runs unconditionally for plugins, so there was no input to disable it and no way to work around it.

The neighbouring bundle-inline-wasm check already flagged these bundles correctly in a few milliseconds; only the reference detector was affected. No other preflight check, and no other part of the action, shares the pattern.

Full Changelog: v1.2.0...v1.2.1