Release v0.20.0 - #28
Merged
Merged
Conversation
…s at the src/consensus tails from the indexer's bytes, citations and requirers repointed (activation registry row 21c)
… re-pinned for those bytes only (activation registry row 28-pin)
The v0.19.0 token read selects tokens.bridge_chains, min_depth, lock_bridge and bridged, four columns that exist only where the indexer migration 2026-09-12-token-bridge-fields.sql has been applied. Naming an absent column is MariaDB 1054 for the whole statement, not a null for one field, so every mainnet token route answered 500 the moment the explorer rolled against replicas that had not taken it, and the fleet had to be held at v0.18.0. getToken now probes information_schema for those columns once per coin and projects the pre-bridge column list where they are missing, with a 1054 recovery behind the probe so a stale or failed probe still answers the page. A negative probe expires after a minute, so applying the migration heals a live explorer without a restart. The degraded body OMITS the bridge fields rather than defaulting them: locks.bridge is seeded false by the empty shape, and false is a positive claim the replica never made, which the wallet acts on by offering an edit a frozen policy forbids. Absence is what every reader of this body already treats as unknown.
The canonical hub-mirror client now asks the connected schema for bridge_transfers and policy_snapshots before reading a watermark from either, instead of firing a statement the server answers 1146 and swallowing the error. Vendored here byte for byte by the indexer's bin/sync-hub-mirror-client.sh, back to back with that commit so neither repo's sibling drift check sees a one-sided twin. Same shape the explorer's own reads take against a replica that has not applied a migration: probe the schema, degrade on what it actually holds, and say so.
The XBRIDGE handler reads bridge_settlements, a table the indexer's bridge-tables migration creates, and that migration is manual: a replica takes it on its operator's schedule. Naming an absent table is MariaDB 1146 for the whole statement, not an empty result for one section, so every XBRIDGE action page answered 500 against a replica that had not taken it, the same way the token routes did before the reader learned to ask. The handler now probes information_schema for the table once per coin, with a negative answer expiring after a minute so applying the migration heals a live explorer without a restart, and a 1146 net behind the probe for the case where it answered wrong. The degraded body OMITS the whole bridge section rather than emptying it. bridge_pending is the one field on that card a holder acts on, and it means "the settle leg is applied on the other chain and has not landed yet"; reporting it true off a table that was never read would tell them their transfer is in flight on no evidence. An absent key reads as unknown, and the card renders the leg with no settlement claim at all. The shared probe lands as src/db/schema_probe.js so the next reader with the same problem asks the same way. The action-detail golden is regenerated for the one added statement in the two XBRIDGE captures, with every other capture byte-identical.
…a v7 and the seven admission-height SQL tables
…and shared_rows_2 from the indexer)
…0.0 train (dq3 (a)) This reverts commit 22404c2; the token bridge and policy gates stay dark on v0.20.0 and arm on the next train.
This was referenced Sep 17, 2026
… the BTC instant The v0.20.0 family was sized 2026-09-16 20:41Z from last-99-block cadences. LTC testnet then ran at about 82 s per block against the 146.6 s that sizing assumed, pulling its producer boundary to 3.2 h out while BTC's stayed 53.0 h out, and DOGE's drifted 7.5 h early. Two legs of one cross-chain match would have crossed the flag day about two days apart, which is what the same-wall-clock-instant rule exists to prevent. Re-measured 2026-09-17 22:45Z over a trailing window as long as the lead being sized: TBTC 152,891 at 576.7 s per block, TLTC 4,889,190 at 82.5 s, TDOGE 67,904,912 at 27.7 s. BTC is unchanged, still keyed to epoch close 153,216 plus 6 buried; LTC and DOGE are converted onto that same instant, and each consumer is its own producer plus six hours at its own measured cadence rather than a block count carried over from the first sizing. Arms the TRAIN_ACTIVATION 0.20.0 row at testnet 153,116, 106 blocks and about 17 h below the BTC producer. resolveRuleSet reads only the local map, so with no row every block above the boundary keeps resolving under 0.19.0, and a manifest naming 0.20.0 halts a fleet in which no build implements it. Records the cadence-window rule the re-cut used and makes the re-size rule per chain instead of BTC-keyed, so an LTC or DOGE drift past the six-hour ordering margin forces a re-cut the way an overrun BTC height already does. (cherry picked from commit 312f0ae84c3088834d33df6bf9ef00005baa5905)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Title: Release v0.20.0
Summary
Changed
Fixed
Sibling release PRs
Merge order
Merge order: merge after xchain-indexer and before xchain-e2e-test.
CI note
GitHub CI on this branch clones sibling repos at develop, not at this release branch, unless a workflow call passes siblings-ref for release branches. A cross-repo guard failure here can reflect that develop-only comparison rather than a real disagreement with a sibling still on this release branch; check the venue pre-push gate (which ships each companion at its own release branch) before treating a red guard as a defect.