Clean up persistence constants

[TheBlueMatt]

The constants in `lightning::util::persist` are sufficiently long
that its often difficult eyeball their correctness which nearly led
to several bugs when adding async support.

Here we clean up the constants, removing words from them that are clear from context and dropping constants that aren't adding anything.

Based on #4063

[ldk-reviews-bot]

I've assigned @valentinewallace as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[graphite-app]

There's a typo in the constant name on line 994: pCHANNEL_MONITOR_NAMESPACE should be CHANNEL_MONITOR_NAMESPACE. This will cause a compilation error when building.

Suggested change

	let monitor_keys = self.kv_store.list(pCHANNEL_MONITOR_NAMESPACE, "").await?;
	let monitor_keys = self.kv_store.list(CHANNEL_MONITOR_NAMESPACE, "").await?;

Spotted by Diamond



Is this helpful? React 👍 or 👎 to let us know.

[tnull]

nACK from my side, they were intentionally kept expressive and consistent.

[TheBlueMatt]

Okay, but "they were intentionally done this way" isn't really a strong argument for keeping them that way. My point here is that, in writing some persistence logic, I almost screwed it up at least three times, with one missed by reviewers and only caught (luckily) by graphite. That tells me the way we have it is totally the wrong tradeoff. If you prefer some other way of rejiggering them to make it more clear I'm all ears, of course.

[tnull]

Okay, but "they were intentionally done this way" isn't really a strong argument for keeping them that way. My point here is that, in writing some persistence logic, I almost screwed it up at least three times,

I really don't see how a more distinct expressive constant is harder to misuse? Why did you screw up exactly? It looked like a copy/paste mistake?

with one missed by reviewers and only caught (luckily) by graphite.

Glad Graphite caught it, but I doubt there was a review round between the mistake and Graphite discovering it?

That tells me the way we have it is totally the wrong tradeoff. If you prefer some other way of rejiggering them to make it more clear I'm all ears, of course.

The way I see it: they are very expressive, clearly spelling out what they are for and can never be misunderstood across LDK and LDK Node codebases (where we have quite a few more of these, following exactly the same pattern). We also made sure to explicitly always including the corresponding secondary namespace constants for unformity, exactly so that you can't mess up writing "" in the wrong place etc.

FWIW, the only way how to make these more foolproof would be to introduce distinct types for primary namespace / secondary namespace / key instead of having them be generic &str consts so that the typechecker can help us avoid any mixups.

[TheBlueMatt]

Finally got around to rebasing this.

I really don't see how a more distinct expressive constant is harder to misuse? Why did you screw up exactly? It looked like a copy/paste mistake?

The biggest difference here is that its incredibly easy to swap CHANNEL_MONITOR_PERSISTENCE_PRIMARY_NAMESPACE and CHANNEL_MONITOR_UPDATE_PERSISTENCE_PRIMARY_NAMESPACE. Because both are so long, and the relevant bit is in the middle of the constant, its nearly impossible to spot issues while glancing through a diff. Also, because both are used constantly near each other, its very easy to copy+paste the wrong one.

Glad Graphite caught it, but I doubt there was a review round between the mistake and Graphite discovering it?

IIRC there was one in one instance. Ignoring that, though, I regularly missed it while looking back at code while I was committing it.

The way I see it: they are very expressive, clearly spelling out what they are for and can never be misunderstood across LDK and LDK Node codebases (where we have quite a few more of these, following exactly the same pattern).

Just including every possible word in a constant isn't always the right answer :). Yes, it makes it more clear if you stop and read the full mouthful, but when reading code you rarely do, that would be a waste of time. If there's ambiguity in what the KEY or NAMESPACE might refer to, a possibly-more-readable approach may be to simply use lightning::util::persist and then refer to things as persist::NETWORK_GRAPH_KEY, which both has the relevant context but avoids having yet more words in the constant name.

We also made sure to explicitly always including the corresponding secondary namespace constants for unformity, exactly so that you can't mess up writing "" in the wrong place etc.

Yea, fair, there's definitely a valid concern there, though given the secondary namespaces are only used for monitor updates I'm not entirely sure its worth having a second constant. Its a bunch of additional overhead and potential for confusion in accidentally swapping the namespace constants which seemed worth just removing. Does the secondary namespace get used much in ldk-node?

[codecov]

Codecov Report

❌ Patch coverage is 77.21519% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.33%. Comparing base (e42e74e) to head (5ffee02).

Files with missing lines	Patch %	Lines
lightning/src/util/persist.rs	52.00%	6 Missing and 6 partials ⚠️
lightning-background-processor/src/lib.rs	84.61%	5 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4105      +/-   ##
==========================================
- Coverage   89.33%   89.33%   -0.01%     
==========================================
  Files         180      180              
  Lines      138055   137929     -126     
  Branches   138055   137929     -126     
==========================================
- Hits       123326   123213     -113     
+ Misses      12122    12117       -5     
+ Partials     2607     2599       -8     

Flag	Coverage Δ
fuzzing	33.60% <4.00%> (+0.02%)	⬆️
tests	88.72% <77.21%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.