BUG: The initial snapshot has latest_seen_timestamp 0 #95
Comments
When we write an update, we have to include a timestamp that represents both the the time that the client will use to fetch the next diff and the timestamp used as a reference point when adding updates to the network graph (the client actually uses the included timestamp minus two weeks). Because of the second use, updates were being generated with the highest timestmap of all included updates, rounded down to the nearest update-interval multiple (because of the first use). In practice, because we expect to see many updates in any hour window, this meant we were really calculating the generation reference timestamp in a very indirect way. Here we simply change to using the reference timestamp directly. This updates regtest results when generating an initial sync against an empty graph to include a real timestamp, rather than 0, though this shouldn't impact clients' correctness. Fixes lightningdevkit#95
|
Fixed in #96 though I'm not entirely sure why this is an issue in practice. |
|
Hm, I see, maybe the issue is not that |
|
Hmm, so looking at your logs, it looks like at |
Description:
The initial snapshot has
latest_seen_timestamp0.Steps to Reproduce:
0.binExpected Behavior:
A reasonable timestamp.
Additional Context:
If I restart the server, it generates new snapshots with non-zero
latest_seen_timestamp.See attached log files: rgs-server.logs.txt.
Database snapshot after the first start: db.1.sql.txt.
Database snapshot after the second start: db.2.sql.txt.
The text was updated successfully, but these errors were encountered: