fix: release workflow when there's no previous release.
Signed-off-by: KtorZ <[email protected]>
Signed-off-by: KtorZ <[email protected]>
The branch added a 'Maybe FsPath' export-path field to LSMArgs but did not update db-analyser's call site. Rather than hardcoding it, surface the LSM configuration (bloom-filter salt and snapshot export directory) via a new 'mkLSMConfig' method on 'HasProtocolInfo' (default: none). The Cardano instance reads them from the node config's LedgerDB.LSMSalt and LedgerDB.LSMExportPath fields, so db-analyser uses the same salt the database was created with (needed for exported snapshots to be importable) and can export snapshots as it stores ledger states. Falls back to a random salt when none is configured. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Built on top of #2060 # What changed ### 1. From #2060, Percolate the replay goal from `--analyse-from` `openLedgerDB` previously hard-coded the replay goal to `genesisPoint`. Because `initialize` rejects every snapshot whose slot is more recent than the replay goal (`InitFailureTooRecent`), a genesis goal rejected *all* snapshots, so db-analyser always restarted from genesis and silently ignored `--analyse-from`. The replay goal is now derived from the `--analyse-from` argument (genesis when it is omitted), so snapshot selection considers the on-disk snapshots and picks the newest one that is not more recent than the requested slot. ### 2. Replay up to `--analyse-from` before analysing With (1), the LedgerDB starts from the newest snapshot at or before `--analyse-from`, but it was opened with an *empty* stream — no blocks were replayed. When no snapshot existed exactly at the requested slot, the ledger state (and therefore the analysis) silently began at the older snapshot's tip rather than at `--analyse-from`. `openLedgerDB` is now handed the ImmutableDB and replays blocks on top of the chosen snapshot up to the replay goal, so the ledger state is exactly at `--analyse-from` before the analysis begins. The replay stream stops at the first block past the goal, mirroring the `StartFromPoint` behaviour where the analyse-from block is the anchor and processing starts after it. When a snapshot already sits exactly at the requested slot, the stream stops immediately and no blocks are replayed. If no snapshot exists exactly at the requested slot, db-analyser now emits a warning (the replay from an older snapshot up to the goal can be slow), but still proceeds. ### 3. Remove the unused `lgrStartSnapshot` `LedgerDbArgs.lgrStartSnapshot :: Maybe DiskSnapshot` was introduced to let db-analyser start from a specific snapshot, but it was only ever set to `Nothing` and db-analyser never used it. Its purpose is now served by the replay-goal-based snapshot selection above, so the field and the corresponding `Maybe DiskSnapshot` argument of `initialize` are removed. **Breaking change** for downstream consumers of `LedgerDB.LedgerDbArgs`. The node only constructs `LedgerDbArgs` via `defaultArgs` and never set this field, so it is unaffected. A changelog fragment is included.
Carry the prover input into the clerk, return the verifier data alongside the aggregate signature, and accept optional verifier data on verification.
Feed the ancillary proof input into multi-signature creation and persist the returned verifier data on the certificate.