Skip to content

Cake update v2 - #2

Open
KarimMokhtar wants to merge 50 commits into
new-indexfrom
cake-update-v2
Open

Cake update v2#2
KarimMokhtar wants to merge 50 commits into
new-indexfrom
cake-update-v2

Conversation

@KarimMokhtar

Copy link
Copy Markdown

No description provided.

Rafael Saes and others added 30 commits July 18, 2024 12:49
Merged latest blockstream changes from new-index branch while preserving
silent-payment functionality from cake-update-v1.

Key changes:
- Updated mempool update logic to handle chain tip changes
- Added ZMQ support and block hash notifications
- Improved reorg handling in indexer
- Preserved silent-payment tweak indexing functionality
- Updated dependencies (zmq, electrs_macros)
- Resolved conflicts in all affected files
KarimMokhtar and others added 20 commits February 14, 2026 23:58
…rite_rows` and adding block height to transaction edge rows.
…ansaction addition. Removed redundant comments and improved clarity in transaction indexing logic. Ensured consistent flushing of database writes before updating the synced tip.
…ing the tester instance directly for indexed blockhashes.
…opulated before syncing, allowing for incremental updates after mining a new block.
…y that indexed_headers are populated after the initial sync, ensuring robustness against potential out-of-order header retrieval.
…lent-payments, ensuring required crates like bech32 0.9.1 are included in the vendored cache.
The "Merge new-index branch into cake-update-v1" merge (9dffb84) resolved
the Cargo.lock conflict by taking the upstream side for the crate stanzas
while keeping the `silentpayments` git package from the cake side. That
dropped every package only silentpayments depends on, leaving the lock
internally inconsistent: the `silentpayments` entry referenced
`bech32 0.9.1`, `bitcoin_hashes 0.13.0` and `secp256k1 0.28.2`, none of
which had a [[package]] stanza of their own.

The cargo-based CI jobs do not pass --locked, so they silently repaired
the lock over the network and stayed green. The `nix` job builds with
crane, which vendors strictly from the committed Cargo.lock into a
directory source that replaces crates-io and then builds offline, so the
missing stanzas were unrecoverable:

    error: failed to select a version for the requirement `bech32 = "^0.9"`
    candidate versions found which didn't match: 0.11.0, 0.8.1

Regenerate the lock with the pinned toolchain (cargo 1.75.0, per
rust-toolchain.toml). The change is purely additive: 5 packages added,
none removed, no existing version changed, silentpayments git rev
unchanged.

Verified with `cargo check --locked --release --all-features` (the same
resolution crane performs offline), which now succeeds and compiles
bech32 0.9.1, bitcoin_hashes 0.13.1, secp256k1 0.28.2 and silentpayments.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Plain cargo silently repairs an inconsistent Cargo.lock over the
network, which is how the merge-corrupted lock fixed in the previous
commit shipped unnoticed in February and only surfaced in the nix
job's offline vendored build. With --locked, the fast check job fails
immediately on any lock/manifest mismatch.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ci: fix nix build (bech32 vendoring failure)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants