Request for latest update returns last-day update rather than a dummy one

[TheBlueMatt]

User reported:

if I do an update with a timestamp just a few minutes after the previous update I still get a ~323kb blob and the error failed to update network graph with rapid gossip sync data: LightningError: LightningError { err: "Update had same timestamp as last processed update", action: IgnoreDuplicateGossip }

It seems we should be returning a dummy update if we get a request for the last generation timestamp. Also, this shouldn't be an error but that's a rust-lightning issue.

[jdenken]

Good day,
After reading the code, I think it already would return an empty update if the correct timestamp is used by the client, so I have sent the PR #18 that fixes the timestamp that we return to the client. On that note, I have not found any code that actually issues requests to the gossip server, can you please point me to any realistic example? I think I know how to construct the client myself, but I'm trying to understand how the client from he user report derives the last_sync_timestamp timestamp (does it use last_rapid_gossip_sync_timestamp?), as that would help to further diagnose the problem.

[TheBlueMatt]

I don't have a full example client handy, but the high-level of how clients are expected to function is covered at https://docs.rs/lightning-rapid-gossip-sync/

[TheBlueMatt]

The specific issue here is that we should generate a "dummy" update every time we generate updates - one that applies no channel/node changes. That dummy update should then be symlink'd from the current last-seen-timestamp, ensuring that if a client requests the gossip data, then requests it again (using the last-seen-timestamp we just gave them) they'll get a dummy update rather than an update with some channels in it.

[arik-so]

Should be fixed by #29.