-
Notifications
You must be signed in to change notification settings - Fork 138
feat: RFQ forward history accounting and query API #1921
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces a valuable feature for tracking RFQ forward history, complete with a new database table, RPC endpoint, and CLI command. The implementation is well-structured, spanning the database, business logic, and presentation layers.
My review includes a suggestion to improve the CLI's user experience by providing explicit error handling for mutually exclusive flags. I've also pointed out a minor style guide violation in the new test files regarding function comments.
Overall, the changes are solid and the new functionality is well-tested.
| assetIDStr := ctx.String(assetIDName) | ||
| groupKeyStr := ctx.String(groupKeyName) | ||
|
|
||
| if assetIDStr != "" || groupKeyStr != "" { | ||
| req.AssetSpecifier = &rfqrpc.AssetSpecifier{} | ||
|
|
||
| if assetIDStr != "" { | ||
| assetID, err := hex.DecodeString(assetIDStr) | ||
| if err != nil { | ||
| return fmt.Errorf("invalid asset ID hex: %w", | ||
| err) | ||
| } | ||
| req.AssetSpecifier.Id = &rfqrpc.AssetSpecifier_AssetId{ | ||
| AssetId: assetID, | ||
| } | ||
| } else if groupKeyStr != "" { | ||
| groupKey, err := hex.DecodeString(groupKeyStr) | ||
| if err != nil { | ||
| return fmt.Errorf("invalid group key hex: %w", | ||
| err) | ||
| } | ||
| req.AssetSpecifier.Id = &rfqrpc.AssetSpecifier_GroupKey{ | ||
| GroupKey: groupKey, | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current logic for handling --asset-id and --group-key flags can lead to unexpected behavior. If a user provides both flags, the --group-key is silently ignored due to the else if structure. It would be better to return an error to the user, informing them that these flags are mutually exclusive.
I suggest adding a check to handle this case explicitly.
assetIDStr := ctx.String(assetIDName)
groupKeyStr := ctx.String(groupKeyName)
if assetIDStr != "" && groupKeyStr != "" {
return fmt.Errorf("cannot specify both --%s and --%s",
assetIDName, groupKeyName)
}
if assetIDStr != "" || groupKeyStr != "" {
req.AssetSpecifier = &rfqrpc.AssetSpecifier{}
if assetIDStr != "" {
assetID, err := hex.DecodeString(assetIDStr)
if err != nil {
return fmt.Errorf("invalid asset ID hex: %w",
err)
}
req.AssetSpecifier.Id = &rfqrpc.AssetSpecifier_AssetId{
AssetId: assetID,
}
} else if groupKeyStr != "" {
groupKey, err := hex.DecodeString(groupKeyStr)
if err != nil {
return fmt.Errorf("invalid group key hex: %w",
err)
}
req.AssetSpecifier.Id = &rfqrpc.AssetSpecifier_GroupKey{
GroupKey: groupKey,
}
}
}26178d0 to
5e71beb
Compare
Pull Request Test Coverage Report for Build 20461350246Details
💛 - Coveralls |
Adds a new rfq_forwards table migration with its associated models and queries: - Query forwards with filters - Count forwards - Sum forward fees
- Adds the forward store in the DB layer. - Moves business entities from the DB layer to the RFQ layer. - Defines Forward Store interface and entities.
On settle event from LND, log the RFQ forward event into the DB.
with pagination and filters.
5e71beb to
ecf9c3e
Compare
ecf9c3e to
6edde15
Compare
Adds a new rfq_forwards table migration with its associated models and queries: - Query forwards with filters - Count forwards
- Adds the forward store in the DB layer. - Moves business entities from the DB layer to the RFQ layer. - Defines Forward Store interface and entities.
On settle event from LND, log the RFQ forward event into the DB.
with pagination and filters.
72a580d to
acff712
Compare
GeorgeTsagk
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Direction looking good
| id INTEGER PRIMARY KEY, | ||
|
|
||
| -- settled_at is the unix timestamp when the forward settled. | ||
| settled_at BIGINT NOT NULL, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be going a bit too far here, but what about also storing an "opened at" field?
This way we're exposing information to the portfolio pilot that can be of essence:
- Fast HTLCs are better than long-held HTLCs (especially for tap, where you don't want to have an open position for too long)
- We could also even store forward events that were never settled. So if someone is locking liquidity or performing a jam attack over the channel it can be detected by observing the rfq_forwards, which potentially may never have their
settled_atfield set (afailed_atfield would be complementary here)
| asset_amt BIGINT NOT NULL, | ||
|
|
||
| UNIQUE(chan_id_in, htlc_id) | ||
| ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems like you also removed the sats in/out fields that were previously here?
even though the fee calculation was off, I think it would be nice to keep those field for sanity
Right now you can derive the msat amount that was in theory forwarded by combining asset units with asset rate, but the actual recorded amount would be nice to have (these 2 can also be off by design)
| CREATE TABLE IF NOT EXISTS rfq_forwards ( | ||
| id INTEGER PRIMARY KEY, | ||
|
|
||
| -- settled_at is the unix timestamp when the forward settled. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are the following commits meant to be fixups? If so some context on the fixup commit itself is needed, as many of the changes are not self explanatory (much of the previous diff is reverted)
|
@jtobin: review reminder |
This PR adds RFQ forward history tracking, allowing edge nodes to monitor and query their asset forwarding activity and fee revenue. Edge nodes need visibility into their RFQ forwarding activity to:
Changes
rfq_forwardstable to store forward eventsQueryRfqForwards: New RPC endpointtapcli rfqrpc forwards: Query forward history from CLI with filters--min-timestamp,--max-timestamp,--peer,--asset-id,--group-key,--limit,--offsetFixes #1005