v26.39.0 release notes

[bosconi]

Release notes for the v26.39.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.

Currently applied: rc.1, rc.2, rc.3 — Cloud 2026-08-27 / Self-Managed 2026-08-28, estimated as the first Thursday strictly after the v26.39.0-rc.1 tag (2026-08-21, a Friday), plus one day. Neither rc.2 nor rc.3 changes the estimate, because that Thursday has not yet passed. Both v26.37.0 and v26.38.0 shipped a day early against this same estimate, so treat the pair as an upper bound.

rc.3 is an empty increment — its commit carries no diff. The cut was run by hand to recover from an earlier rebase, so it is not a descendant of rc.2 (compare v26.39.0-rc.2...v26.39.0-rc.3 reports ahead 2, behind 2). Its two commits are the version bump b99895189, which is not user-facing, and 6a64c9b32 — a second cherry-pick of #38399 onto the same parent 8e3e1ddd95 as rc.2's 9a25cb448, with an identical subject and an identical 16-file change list. That fix already ships as a Bug Fixes entry from the (rc.2) commit, and snapshots are disjoint by construction, so it stays there rather than appearing twice. The (rc.3) commit exists only so the branch's commit-subject ledger records the snapshot as applied.

Merge ordering: this branch was cut from a main that contains neither the v26.38.0 nor the v26.38.1 section (#38204 and #38365 are both still open), so ## v26.39.0 currently sits directly above ## v26.37.0. It must end up above both v26.38 sections — whichever of these PRs merges last needs its section placed relative to the others by hand. The same applies to the operator-compatibility table row.

For the release owner — decisions worth a look before merge:

• Six flag-gated items were held as Borderline pending a call on whether their flags are on in production: the frontend OCC read-then-write path (enable_adapter_frontend_occ_read_then_write), CREATE METRIC SINK (enable_metric_sink), parallel MySQL snapshots (mysql_source_snapshot_parallelism), and the error-multiplicity fix (enable_compute_error_distinct, code default now true but LaunchDarkly still serving false).
• Two security fixes were held as Borderline rather than published (CNS-108 console: DOT fix for DataFlow Viz #38272, environmentd: quote the SQL the memory visualizer builds #38369) because both sit on internal introspection surfaces rather than documented product surfaces.
• CLO-190: persist: refresh Azure workload identity tokens from rotated file #38178 (Azure workload identity token refresh) is omitted here because it was already published as v26.38.1's single entry; it appears in the v26.39.0 tracking issue only as its main merge.
• The SUBSCRIBE hang fix (compute: derive time dependence from the imports a dataflow reads #38260) requires replica dataflow expiration to be active. If expiration is off by default in production, that bullet should come out.
• rc.2's single entry (adapter: hydrate migrated builtin MVs before 0dt cut-over #38399, the zero-downtime cut-over fix) applies only to upgrades whose old leader is v26.17 or later — Cloud always qualifies, Self-Managed does not necessarily, and the code calls upgrading from before v26.17 "a real case, not a hypothetical." The bullet is published under both date lines; worth deciding whether that asymmetry should be stated. Its flag (enable_0dt_hydrate_migrated_builtin_mvs) is a break-glass kill switch defaulting to true, not a rollout lever, so it was not held Borderline.
• If you would rather adapter: hydrate migrated builtin MVs before 0dt cut-over #38399 appear under rc.3 than rc.2, the correct edit is to move the existing bullet, not to add a second one.

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: 13 — review borderline calls, rc.2: 0 — none, rc.3: 1 — the duplicate cherry-pick of #38399