Skip to content

Conversation

@jasagredo
Copy link
Contributor

@jasagredo jasagredo commented Jun 26, 2025

Description

Integrate the LSM trees as a new backend for the LedgerDB.

@jasagredo jasagredo changed the base branch from main to coot/cardano-diffusion-integration July 17, 2025 10:30
@jasagredo jasagredo force-pushed the js/lsm1 branch 6 times, most recently from 4eaa608 to 97d30af Compare July 17, 2025 13:54
@jasagredo jasagredo marked this pull request as ready for review July 17, 2025 15:52
@coot coot force-pushed the coot/cardano-diffusion-integration branch from 37619a9 to d62dc42 Compare July 18, 2025 09:23
@jasagredo jasagredo changed the base branch from coot/cardano-diffusion-integration to main July 21, 2025 09:53
@jasagredo jasagredo force-pushed the js/lsm1 branch 2 times, most recently from dad593f to 26e6455 Compare July 21, 2025 11:43
@jasagredo jasagredo force-pushed the js/lsm1 branch 2 times, most recently from 12a1acb to 4119afa Compare July 29, 2025 10:55
jasagredo and others added 4 commits October 2, 2025 16:21
An extra version of `text` is in the plan.json as a dependency of a
`custom-setup` or `build-tool-depends`. Using `exactDeps = true` prevent those
from getting into the plan.json.

Co-authored-by: Hamish Mackenzie <[email protected]>
Comment on lines +115 to +120
error $
unlines
[ "There was an error deserializing a TxOut from the LSM backend."
, "This will likely result in a restart-crash loop."
, "The error: " <> show err
]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not thrilled to see error here. Still looking to understand where the fromTxoutBytes is used from perhaps it's possible to gracefully handle the error condition without calling error?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looked at from fromTxInBytes and fromTxOutBytes and error calls therein. Couple of questions:

  1. Should we introduce module level Error type and handle such conditions gracefully?
data Error = TxOutDecodingError SomeError | TxInDecodingError SomeError | InternalError Text

Even though we're calling from functions in IOLike m, it would be very useful to have structured error types such that we can eventually also provide machine readable errors in agreed upon format etc.

  1. What's our take on error generally?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general we don't like error but for unrecoverable situations like this one it is somewhat OK. We cannot handle such an error in any meaningful way so we just have to crash. Having a module level Error type would help us with readability of the error though...

@jasagredo jasagredo added this pull request to the merge queue Oct 9, 2025
Merged via the queue into main with commit 31a1bef Oct 9, 2025
17 checks passed
@jasagredo jasagredo deleted the js/lsm1 branch October 9, 2025 14:33
@github-project-automation github-project-automation bot moved this from 👀 In review to ✅ Done in Consensus Team Backlog Oct 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

7 participants