It was an issue when reviewing commit by commit yes, I would recommend just squashing the format fix commit with the earlier commit which formatted the code

Alternative to @2Fast2BCn work. The key design decisions are

• do not use a local cache for banned vtxos. It is complex and adds little
• include is_banned in the is_spendable check
• banning occurs by block-height. This ensures we cannot ban after vtxo expiry by accident

• check or remove this line after you've added a CHANGELOG entry or if your PR doesn't need one (they should go into CHANGELOG/unreleased/)

Duncan Dean (3d12cce5) at 17 Mar 13:01

... and 5 more commits

This test basically tests a serialization round-trip and fills out all defaults. It then complains that newly added stuff is missing.

We might come up with a better test

We periodically poll in spawn_cln_settler loop now.

Erik De Smedt (6da53a1c) at 17 Mar 12:08

... and 49 more commits

I really don't want to ship any adaptor that doesn't support actual querying for usage in production. Isn't the whole point of indexeddb that we can use the index field to make such queries?

oh wow so we're not even sending JSON objects but native serde-to-js-object serialization. that's neat! I had to ask claude if that serializer is "human readable" configured or not and it seems yes, so it should behave similar to JSON.

don't use log:: prefix

Was there a reason to call cargo update for this commit? Were the tests not working?

If I do

$ cargo checkout $(git merge-base HEAD master) ./Cargo.lock
$ just check
$ git reset

It seems a lot less changes to Cargo.lock are required.

EDIT: I think you might have done this because the esplora thing bugging you? That should be fixed by rebasing on master :)

Have you considered the option to have lazy initialization of partition object stores?

use context (everywhere). this is a very annoying claude-ism that I keep seeing over and over

Duncan Dean (d34ef7c0) at 17 Mar 10:35

... and 104 more commits

Erik De Smedt (fbe72461) at 17 Mar 10:17

... and 12 more commits

• check or remove this line after you've added a CHANGELOG entry or if your PR doesn't need one (they should go into CHANGELOG/unreleased/)

do we have aim at ensuring backward compatibility on config ?

nit: this commit would be useful as a first commit to understand the purpose of bark-archivist

can fixup this commit in 19e7a4da ?

Steven Roose (6afaf3b5) at 17 Mar 09:46

... and 2 more commits

yea did that