routing: add mission control import rpc#5061
Conversation
There was a problem hiding this comment.
nit: maybe. bump this to Infof? would also make a nice addition to log how many were added/ignored! that way info users only see:
[CRTR] Importing history snapshot to mission control
[CRTR] Imported XX/YY fresh results from mission control history snapshot.
bhandras
left a comment
bhandras
left a comment
There was a problem hiding this comment.
Nice feature, mostly nits. 🚀
There was a problem hiding this comment.
Why wouldn't we want to simply overwrite? I see it perfectly valid to just overwrite with an old dump. WDYT?
There was a problem hiding this comment.
Not sure why would we want to overwrite our existing fresh results with older results? Since the goal in doing this is to get a hotter cache
There was a problem hiding this comment.
This is very nice, maybe could also add csv import? (Otherwise MC may change if node is busy).
There was a problem hiding this comment.
What do you by MC might change?
I was picturing the main use case for bulk-import to be the rpc? Since you can pass the request from QueryMissionControl directly in, adding a csv is an extra step. Could add an option to feed the json output in like we do for SendToRoute if we want to do bulk import via cli?
Roasbeef
added
enhancement
carlaKC
force-pushed
the
4483-importmissioncontrol
branch
from
79552ac to
68e9eae
Compare
|
Re making the "experimental'-ness of RPCs more explicit, offline Conner suggested an |
|
@Roasbeef sounds good to me 👍 |
carlaKC
force-pushed
the
4483-importmissioncontrol
branch
from
68e9eae to
01201ef
Compare
carlaKC
requested review from
bhandras and
cfromknecht
and removed request for
bhandras and
cfromknecht
cfromknecht
left a comment
cfromknecht
left a comment
There was a problem hiding this comment.
looks just about ready! last comment is the addition of the X prefix to the rpc method and messages
carlaKC
force-pushed
the
4483-importmissioncontrol
branch
from
01201ef to
cb97762
Compare
|
Getting back to the privacy and space aspects: one option would be to only share successes. I think that priming with just the success amounts for each channel is already very effective. The failures will decay anyway. Users could choose to prune their exports before sharing. |
Yeah that may make sense for certain classes of user for this RPC, what's implemented right now doesn't preclude that. |
…rical-sync * commit 'b444ae37125d32eaab1d68e73c4b1b12bf6451bc': backport lightningnetwork#5061 - routing: add mission control import rpc backport lightningnetwork#4909 - routing: allow runtime updates to mission control config
5 participants
This PR adds in-memory mission control import. We take a very simple approach, as outlined in the original issue, where we only import results that are fresher than our current records.
Fixes #4833