Cassandra 3.11 to 4.0 Rolling Upgrade: Where Does the Snapshot Rollback Window Actually Close?

A rolling upgrade from Cassandra 3.11 to 4.0 needs a rollback plan, and the unresolved question is where that plan stops working if the upgrade fails midway. The documented per-node sequence (drain, snapshot, then restart on 4.0) leaves pre-upgrade snapshots as hard links to existing SSTables, and the 3.11 binary can neither read 4.0-format SSTables nor replay 4.0 commitlog segments.

That suggests the real boundary is the first write a 4.0 node accepts — its flushed memtables and commitlog segments are immediately new-format — not the point where nodetool upgradesstables or compaction rewrites older files. The two events are often conflated, muddying the upgradesstables-timing decision.

Constraints: the mixed-version window rules out DDL and repairs; coexisting old- and new-format SSTables roughly double data-directory usage; and 4.0's changed TTL expiration handling (the 2038 local-expiration overflow) adds caveats for long-TTL tables during the window. Flags and limits vary by release, so NEWS.txt for the exact pair needs confirming.

1. Is the practical rollback limit per node the first post-upgrade write, with upgradesstables timing affecting only conversion of pre-existing files?
2. For a multi-day rollback window, is deferring upgradesstables a supported posture, or does it only prolong mixed-format disk use without real rollback benefit?
3. Does snapshot restore on a partially upgraded cluster require reverting every node that already accepted 4.0 writes, even where old-format SSTables remain on disk?