Not a bug: 3511/3516 are private preview builds whose peer-link migrations were numbered ahead of main. Reconciled per machine instead (moved to 070-072 after main's 068-069).
Preview 3702 cannot start on a 3511/3516 database: peer-link migrations moved from 68–70 to 70–72#25289
What happened
Upgrading a preview install from 0.1.2-preview.20261022.3511 (or 3516) to 0.1.3-preview.20261026.3702 fails at startup, and the service crash-loops:
| 1 | MigrationError: This database's migration history would skip required schema migrations: 68_ShellStopRequestIndex (recorded: PeerLinks), 69_ThreadMessageSearch (recorded: PeerLinkFence), 70_PeerLinks (recorded: WaitingLinkRequestIndex). The migrator skips every id up to the highest recorded id (70), regardless of name. |
The peer-link migrations moved between the two preview tags:
| id | 3511 / 3516 | 3702 (and main) |
|---|---|---|
| 68 | PeerLinks | ShellStopRequestIndex |
| 69 | PeerLinkFence | ThreadMessageSearch |
| 70 | WaitingLinkRequestIndex | PeerLinks |
| 71 | — | PeerLinkFence |
| 72 | — | WaitingLinkRequestIndex |
So every database written by 3511/3516 has the peer-link names at 68–70 and lacks ShellStopRequestIndex and ThreadMessageSearch. Nightly installs are unaffected: a nightly 3655 database already had 68/69 under the new names and upgraded to 3702 cleanly.
Seen on a fleet of 42 preview workers plus one orchestrator host, all on 3511/3516. The first worker we tried was rolled back to 3511 by our rollout script. The rest are held on 3511 until there is an upgrade path.
Expected
3702 recognizes this exact recorded history (68–70 = PeerLinks, PeerLinkFence, WaitingLinkRequestIndex) and upgrades it. It would renumber those rows to 70–72 and then apply 68 ShellStopRequestIndex and 69 ThreadMessageSearch, which the "skip every id up to the highest recorded" rule currently blocks. 071 (ALTER TABLE ... ADD COLUMN fenced) and 072 (CREATE INDEX without IF NOT EXISTS) cannot simply be re-run.