## Context
Since v2.19.0 rolled out to prod (2026-07-07), workers are flooded with
mid-body fetch failures — `Invalid response body while trying to fetch
…: Premature close` — on Gmail message import (Sentry TWENTY-SERVER-D3X,
~22k events/day, ~1k users) and, simultaneously, on Cloudflare
custom-domain checks (TWENTY-SERVER-HXW/HXT). Both code paths were
unchanged between v2.18.5 and v2.19.0; their only shared layer is the
runtime HTTP stack.
The one relevant change in v2.19.0 is #22529: the base image bump
`node:24.16.0-alpine` → `node:24.17.0-alpine`. Node 24.17.0 patched
exactly the components under these fetches:
- `http`: CVE-2026-48931 — idle keep-alive sockets in the Agent pool now
get `socket.resume()` + a destroy-on-data guard on every free→reuse
cycle
- `deps`: llhttp 9.4.2 (security bump of the HTTP parser that decides
when a chunked body is complete)
The messaging import loop cycles the same keep-alive socket through the
pool once per message fetched, so any per-cycle failure probability is
amplified by prod volume. (Note: undici's equivalent CVE fix needed two
follow-up commits for races of this exact kind — sockets destroyed while
freshly handed to a request.)
## What this PR does
Pins the base image back to `node:24.16.0-alpine3.23` (same digest
v2.18.5 shipped with) on all four stages, and updates the security note
accordingly.
This doubles as the definitive root-cause test: if the premature-close
rate drops back to its historical baseline on the rebuilt image, the
24.17.0 HTTP-stack change is confirmed and we can file a solid upstream
report to nodejs/node.
## Trade-off — please weigh in
This re-exposes what #22529 fixed: 24.16.0 statically links OpenSSL
3.5.6, so the scanner will re-flag CVE-2026-48930 (TLS embedded-nul
hostname authority rebinding, CVSS 9.8) on the node binary. There is no
24.x release newer than 24.17.0 yet. The Dockerfile carries a TODO to
re-bump as soon as a fixed 24.x ships.
## Related
- #22671 classifies `ERR_STREAM_PREMATURE_CLOSE` as a transient
(retryable) network error at the application level — worth landing
regardless of this rollback, since sync channels currently hard-fail to
`FAILED_UNKNOWN` on what is a plain network race.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22673?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
Charles Bochet
840c41e6b7
