Files
OmniRoute/tests/unit/compression
Marco 55b6ca6573 fix(compression): fall back in-process when the compression worker fa… (#13637)
* fix(compression): fall back in-process when the compression worker fails (#13145)

The worker pool resolved every worker fault with the *uncompressed* body instead
of reporting it. `PendingJob` had no reject path at all, so a thread error, a
worker exit, a dispatch timeout, or an engine error posted back as
`type: "error"` all resolved as `{ compressed: false, stats: null }`.

`applyCompressionAsync` then treated that as a legitimate "nothing to compress"
result and returned it as-is, so the request reached the provider uncompressed
while the response header still announced the selected plan ("stacked") — the
header is emitted before the pipeline runs. Nothing was logged at any level, and
`compression_analytics` stayed empty because rows are only written when a
compressed result is reported. The net effect was compression silently disabled
for every worker-eligible request.

The worker is a throughput optimisation, not a behavioural variant, so a worker
fault must degrade to the in-process pipeline rather than to no compression:

- `PendingJob` gains `reject`; `fail()` delegates to a new `abort()` that clears
  the slot timeout and rejects with a diagnostic cause (thread error, exit code,
  or timeout budget).
- An `error` message from the worker is propagated instead of being swallowed.
- `applyCompressionAsync` catches the rejection and falls through to the
  in-process path, logging the cause. The logger is imported lazily and
  defensively: `compressionWorker.ts` imports this module, so a static import
  would pull the logger into the worker bundle, and a logging failure must never
  be able to break compression itself.

`close()` keeps resolving with the unchanged body — shutdown is not a fault.

The regression test drives a real worker fault via
`OMNI_COMPRESSION_WORKER_TIMEOUT_MS` rather than mocking the module, since this
project's tsx/ESM + node:test setup has no `mock.module()` support. Its options
are fully populated on purpose: `runCompressionAsync` forwards them into
`workerOptions`, and `isStrictlySerializable` rejects an object holding
`undefined` values — which would route the test through the in-process path and
assert nothing. Production requests always carry all of those fields, which is
why the worker path is taken there.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LGJQT3E6iJZq4zNGwfjkPs

* fix(compression): keep the timeout path uncompressed, retry only fast worker faults (#13145)

Review follow-up: the in-process fallthrough ran the full pipeline on the main
event loop for *every* worker fault, including a dispatch timeout. A timeout
means the worker already spent its whole budget on that body, so re-running the
same CPU-bound work inline would stall other in-flight requests — strictly worse
than not compressing on a shared gateway.

Faults are now typed by whether recovery is cheap:

- `CompressionWorkerError.retryInProcess` distinguishes fast faults (thread
  error, worker exit, engine throw — no work was done, so the in-process path
  costs what the worker would have) from a dispatch timeout.
- Timeouts keep the original degrade-to-uncompressed behaviour, but are now
  reported. The defect this PR fixes is the silent swallow, not the degrade.

Also strips `reject` from the structured-clone wire job. It is a function, so
leaving it on the object handed to `postMessage` threw `DataCloneError` before
the worker ever saw the job — turning every dispatch into an immediate fault.

Adds the missing `changelog.d/fixes/` fragment.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(compression): narrow the worker thread-error type for typecheck:core

@types/node 26 types the Worker "error" event payload as unknown, not
Error, so `error?.message` failed typecheck:core (TS2339). Narrow with
an instanceof check before reading .message.

Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
Co-authored-by: marcs7 <marcs7@users.noreply.github.com>
2026-09-18 13:13:25 -03:00
..
2026-06-30 06:54:29 -03:00
2026-06-15 03:32:11 -03:00
2026-06-09 22:57:12 -03:00
2026-06-28 06:58:29 -03:00
2026-06-28 06:58:29 -03:00
2026-06-21 08:56:51 -03:00
2026-06-23 17:06:18 -03:00
2026-06-23 17:06:18 -03:00
2026-06-23 17:06:18 -03:00
2026-06-23 17:06:18 -03:00
2026-06-23 17:06:18 -03:00
2026-06-23 17:06:18 -03:00
2026-06-23 17:06:18 -03:00
2026-06-23 17:06:18 -03:00
2026-06-27 09:07:12 -03:00
2026-06-27 09:07:12 -03:00
2026-06-27 09:07:12 -03:00
2026-06-19 06:49:01 -03:00
2026-06-29 08:40:06 -03:00
2026-06-29 08:40:06 -03:00
2026-06-27 09:07:12 -03:00
2026-06-27 09:07:12 -03:00
2026-07-02 10:47:13 -03:00
2026-06-29 08:40:06 -03:00
2026-06-29 08:40:06 -03:00
2026-06-29 08:40:06 -03:00
2026-07-02 10:47:13 -03:00
2026-06-29 08:40:06 -03:00
2026-06-29 08:40:06 -03:00
2026-06-29 08:40:06 -03:00
2026-06-29 08:40:06 -03:00
2026-06-29 08:40:06 -03:00
2026-06-29 08:40:06 -03:00
2026-06-20 07:09:43 -03:00
2026-06-19 06:49:01 -03:00
2026-06-29 08:40:06 -03:00
2026-06-29 08:40:06 -03:00
2026-06-29 08:40:06 -03:00
2026-06-29 08:40:06 -03:00
2026-06-29 08:40:06 -03:00
2026-06-30 06:54:29 -03:00
2026-06-28 06:58:29 -03:00
2026-06-23 17:06:18 -03:00
2026-06-19 06:49:01 -03:00