[bosconi]

Release notes for the v26.48.0 train. Dates in RC snapshots are provisional until the release ships. One commit is added per snapshot; the final snapshot sets the real dates. Applied so far: rc.1, rc.2, rc.3.

• Content: 2 Feature sections (native GCS for persist; Kafka sink headers GA), 10 Improvements, 1 Guide, 4 Bug Fixes. No Agent Skills section — every agent-skills PR in the windows so far was omitted.
• Scope: 120 PRs across the three snapshots — rc.1 114 (14 included), rc.2 5 (0 included), rc.3 1 (1 included).
• Dates (provisional): Cloud 2026-10-29, Self-Managed 2026-10-30, unchanged across all three snapshots. Both land on the usual Thursday/Friday, and agree with the cadence rule applied to the v26.48.0-rc.1 tag (2026-10-23T02:19:41Z).
• Operator compatibility: row added for v26.48, release date 2026-10-30. Unchanged by rc.2 and rc.3.
• Branch base: main, whose newest published section was ## v26.46.1 when this branch was cut; v26.47.0 and v26.47.1 have since merged in. v26.48.0 stays at the top of the list.

rc.3 increment

One Improvement, for #40065: a read-only environmentd that reboots to pick up DDL changes during zero-downtime upgrade catch-up now restarts in place rather than exiting its container, so Kubernetes no longer applies crash-restart backoff. Not inherited from rc.1 — rc.1 correctly omitted the first attempt (#40029) together with its revert (#40061) as a no-op on main; rc.3 re-lands the behavior in narrowed form, verified as a real change by comparing entrypoint.sh at the v26.47.0 tag (no retry loop) against v26.48.0-rc.3 (re-exec on exit 75). The draft's closing "so zero-downtime upgrades catch up faster" was cut: no cited PR measures an upgrade duration, so the entry claims only the mechanism.

• Not a Bug Fix. 0dt upgrades completed on v26.47.0; the catch-up reboots merely collected backoff delay. Existing behavior improved, so Improvements.
• Residual, deliberately unpublished. A stale read-only process in a replaced pod still restarts in place on these halts until the kubelet kills its container, competing with its replacement for the generation's replicas. The MZ_RESTARTED_IN_PLACE marker check keeps it from booting writable, so it cannot fence the leader — the failure Revert "environmentd: restart halts within the container (#40029)" #40061 reverted. Worth watching if 0dt reports look odd after this ships.
• Testing caveat from the author. K8s recovery: envd on failing node — the nightly environmentd: restart halts within the container #40029 broke — was not run on the branch (it needs the cloudtest kind cluster and image builds). Worth a glance at the nightly for this RC before the final snapshot, since that job is what sank the first attempt.

rc.2 increment — empty, by design

rc.2's commit is empty: no entry was published and the provisional dates did not move. It exists so later runs can see from the commit subject that rc.2 was applied.

The snapshot's single materialize PR, #40189 (upsert drain goes from quadratic to linear — a 400-timestamp tail drains in 0.67 s, 6.5 s → 0.15 s at 100 timestamps), is held at Borderline. It runs only on the v2 upsert path, and enable_upsert_v2 defaults to false at the v26.48.0-rc.2 tag (src/storage-types/src/dyncfgs.rs:504-509); the headline 4x figure needs two further flags on top. The author's own declaration is "Release notes: None. Upsert v2 is gated behind enable_upsert_v2".

⚠️ This is the third train in a row to hold this same flag — v26.44.0-rc.1 (#39041) and v26.45.0-rc.1 (#39044) were both held on enable_upsert_v2, and v26.44.0/final re-verified the default as false at its ship tag. The repetition is itself the thing worth raising. Cutting the other way: the PR names a real production incident (CPU-320) — a source that could not catch up on any replica size — which suggests the lever is on somewhere via LaunchDarkly. Is upsert v2 on for any customer at release? The author wrote both the incident description and the "no note" line in the same body, so this needs the release owner, not a rubric call.

rc.1 — standing warnings

⚠️ Seven PRs in rc.1's tracking issue were already covered by the v26.47.0 train, and none is republished here. v26.47.0 took five RCs whose later ones were cherry-picks onto the release branch; the same PRs appear in this issue because they are also what landed on main for v26.48.0. Four of the seven shipped to Cloud in v26.47.0 on 2026-10-22 — #37653, #39910, #39927, #40036 — so republishing any of them would put duplicate text in front of customers eight days later. The other three (#39903, #39906, #40046) were held at Borderline in v26.47.0 and are held again here, each reason re-checked rather than inherited. The "snapshots are disjoint by construction" guarantee holds within a train, not across trains, so this was caught mechanically by grepping every PR number in the issue against the v26.47.0 snapshot directories. All seven are listed under their own heading in rc.1/omitted.md.

Open questions for the release owner

• Upsert v2 (storage: make the chunked upsert v2 stash time-major #40189, rc.2) — see above. Third consecutive hold on enable_upsert_v2.
• MCP protocol revision 2026-07-28 (mcp: answer 2026-07-28 requests with the spec's status codes (DEX-84) #39698, mcp: add resultType and serverInfo to 2026-07-28 results (DEX-76, DEX-77) #39702, mcp: add caching hints to 2026-07-28 tools/list results (DEX-173) #39703, mcp: answer server/discover on 2026-07-28 requests (DEX-75) #39759, mcp: answer invalid request ids with -32600 and allow the MCP headers in CORS (DEX-182) #39761) — the stack is complete and enable_mcp_protocol_2026_07_28 defaults to false at the tag. The authors say the flag "stays off in production until mcp: answer server/discover on 2026-07-28 requests (DEX-75) #39759 lands", which it now has, so it may well be flipped. Is it on for customers at release? If so this deserves a Feature section rather than an Improvement bullet, since it is what moves auto-mode clients such as Claude Code onto the new revision. Drafted wording is in rc.1/omitted.md.
• Redesigned cluster details page in the Console (console: add redesigned cluster details layout behind a UI preview #39446, console: add data for the redesigned cluster page's resource usage #39507, console: add resource usage charts to the redesigned cluster page #39508, console: add a memory by object card to the redesigned cluster page #39510, console: keep the redesigned cluster page's live data in TanStack DB collections #39607) — clears the Console carve-out's "major new page" bar, but the author states the LaunchDarkly flag cluster-details-page-cns-173 is on in Staging only and "Production needs it too before the preview can be offered there." Self-managed pins it off. Is the preview reachable in Production for v26.48.0?
• Schema projection on the Console's Freshness page (CNS-205 Add Schema projection to Freshness page.  #40031) — a genuine new way to diagnose lag, but the author states the whole Freshness page "is currently behind a feature flag that is only enabled for certain customers in impersonation mode". Is the page generally reachable yet? This is the same page v26.47.0 held for the same reason.
• Time zone data 2026e timing (sql: bump chrono-tz fork to tzdata 2026e #40045) — the author flags the Canadian zone changes as effective 2026-11-01, three days after this train's provisional Cloud date. Tight, but it holds.

Resolved since rc.1: the Kafka sink headers framing question — the GA section on this branch answers it.

Verification notes — rc.1's Step 5 pass cut one drafted entry and rewrote four:

• Cut: a Bug Fix drafted for persist: halt with exit code 168 when a live reader loses its lease #40032 ("halt with exit code 168 when a live reader loses its lease"). The PR's own Problem section is about alerting — mz_persist_lease_timeout_read cannot distinguish a dead reader from a stuck one — and the follow-up it names is a Cloud alerting change. Nothing a customer observes changes.
• tzdata (sql: bump chrono-tz fork to tzdata 2026e #40045): the draft said the Canadian zones move to "permanent daylight saving time", the author's prose. The PR's data table shows a permanent −05/EST and −06/CST — summer offsets kept year-round, but with another zone's standard-time abbreviations, which is what a user sees from AT TIME ZONE. Reworded to what the table supports.
• Hydration memory (compute: bound the heap of correction V2's many-stale-times consolidation #39923): scoped to the consolidation step and the measured outcome (~628 GiB peak, no restart, against every pre-change run exiting on the 849 GiB limit). The PR explicitly says the fix "covers this consolidation path, not the sink's whole footprint"; CPU-317 tracks the rest.
• Kafka clients (storage: create Kafka reader consumers only on workers that own partitions #40026): "55 to 24" is measured on a 4-worker, 11-source setup. The CPU throttling and degraded freshness are observed symptoms of the old behavior at a few hundred sources, not a measured post-change result at that scale, so the entry states the count as the outcome and the throttling as what the count drove.
• environmentd accept backlog (server-core: Raise the listen backlog to 1024 #40035): the author's hedge is kept — "less likely to be restarted", not eliminated, because the PR says "This makes the queue fill later, not never."

Judgment calls a reviewer may want to revisit — #39605 is filed as an Improvement, not a Bug Fix: nothing was incorrect, an unbounded operation gained a bound and a knob. #40101 is filed as a Bug Fix rather than omitted under the internal-logging rule, because credentials reaching the logs is a security defect with a user-visible remedy; only credentials a user inlined rather than wrapped in a SECRET were affected.

Snapshot drafts (with PR links) in mz-skills:

• rc.1: release_notes.md / omitted.md
• rc.2: release_notes.md / omitted.md
• rc.3: release_notes.md / omitted.md

Borderline PRs omitted: rc.1: 12 — omitted.md#borderline, rc.2: 1 — omitted.md#borderline, rc.3: 0

🤖 Generated with Claude Code

[val-materialize]

Links to the pattern page from #40120, which should merge this week. If #40113 merges first, this link 404s until then.

[val-materialize]

Pushed two commits to this branch for the Kafka sink headers GA:

• Merged main into the branch. The branch was behind main, so its base had no v26.47.0 or v26.47.1 entries. The release notes now keep v26.47.1 and v26.47.0 below v26.48.0, and the self-managed operator compatibility table keeps the v26.47.1 and v26.47 rows below v26.48. No history was rewritten.
• doc: v26.48.0 release notes: Kafka sink headers GA
  • Removed the "Kafka sink headers on by default" bullet from Improvements.
  • Added a "Kafka sink headers are generally available" section after "Native Google Cloud Storage for persist". It covers the HEADERS option and the materialize-sink-id header, both GA in v26.48 now that SS-517 - Enable Kafka sink headers feature and sink-id header by default #39908 turns their flags on by default. It links to CREATE SINK: Headers and to the new pattern page.
  • Added a ### Guides section before Bug Fixes with the pattern page.

Related:

• doc: mark the materialize-sink-id header and HEADERS option as GA #39829 removes the private preview callouts from the Kafka sink docs. Merge it when v26.48.0 reaches Cloud on 2026-10-29.
• docs: pattern for transactional downstream loads using the sink ID header #40120 adds the "Transactional downstream updates using Kafka" pattern page linked above. Until it merges, those links 404 (see the inline comment on the Guides line).

🤖 Generated with Claude Code