lightningd: Default value for received_time in listforwards to 0#7744
Conversation
received_time in listforwards` to 0received_time in listforwards to 0
850d836 to
6171cf3
Compare
|
Reintroduced the |
7660e48 to
7e095bf
Compare
received_time in listforwards to 0received_time in listforwards to 0
|
Discovered that the |
b9f89da to
4e8d077
Compare
|
Removed the |
4e8d077 to
97782c6
Compare
|
After more testing, I removed my initial changes to set a default The changeset now just reflect ripping out the |
cfe5bb8 to
8708051
Compare
|
Modified the test to stop & start the |
8708051 to
81650bf
Compare
…lementsProject#7157]) Removes the `COMPAT_V070` functionality for `listfowards`. Changelog-Changed: The `listforwards` command will now return a value of 0 for `received_time` for very old forward attempts.
81650bf to
98c2f26
Compare
|
Reasonable solution, thanks! |
This pull request fixes #7157 by altering the JsonRpc return value of
listforwardsto always return a value for thereceived_timefield, initializing it to0if not found. These values could be missing as a result of forwarding attempts that were created prior the implementation of tracking this data, ostensibly inv0.7.0(?).This also removes the
COMPAT_V070compiler directive logic forforwards.c. Sincereceived_timeisrequiredby the JSON schema, the old backward compatibility strategy is breaking and no longer viable.Alternative implementation approaches
I wasn't 100% sure which layer to address this issue in. Some alternative implementation ideas were:
defaultkey to thereceived_timefield in thelistforwardsresponse definition in the JSON schema here. This didn't produce any change tocln-rpc/src/model.rs, so the assumption is this is unsupported.received_timeas arequiredfield in the response schema here. Decided against this because it felt like more of a breaking change to the API from a client perspective.Create a database migration altering the(see comment below)forwardstable settingreceived_timeto 0.forwards.cprocessed by theCOMPAT_V070compiler directive. The compatibility changes are turned on but they are incompatible with the current schema's field requirement forreceived_time. Need to ask out under which conditions compatibility can be removed. <--- ended up doing this one :)Questions
listforwardsbe removed? <--- ended up doing this :)COMPAT_V*versions in the command schemas,lightning-listfowards.jsonwith the idea of conditionally requiring the field?COMPAT_V070be considered fully deprecated, @cdecker mentioned on Discord it's generally 6 months, but this seems ancient?Important
Open for merging new PRs until the next PR freeze date is confirmed!
Checklist
Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked: