-
Notifications
You must be signed in to change notification settings - Fork 69
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
Remove user fee #2586
Remove user fee #2586
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.
LG
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.
Really nice.
Also needs a change in https://github.com/gnosis/solvers.
Let's hope none of the external solvers break because of this. 🤞
Should we maybe run this commit in staging before merging to see if some of the solvers will run into issues because of it.
cc @harisang to communicate this change to solvers.
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 looks good overall, I'm just somewhat worried about breaking the API for clients and wonder if we can decouple our internal representation (no more user fee) and the external representation (hardcode user fee to 0) in a way that could lower this risk?
#[serde_as(as = "HexOrDecimalU256")] | ||
pub fee_amount: U256, |
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.
How confident are we that this breaking change is not going to shoot us in the foot? I think it would be ok to leave this value on the API level but simply always set it to 0 in code (and document that it's deprecated and always 0 in the API spec). For our internal models (domain, etc), we would want to remove this field however.
The frontend team would like to re-vamp our API and I think it would be ok to defer breaking changes thereto.
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 mentioned field is part of the solvers API. Not sure what frontend has with it? If you got confused and referred to the model
data struct than yes, we still want to keep fee_amount
there.
Solvers API should be kept clean, this moment is good enough to make this change as any other IMO (actually, would have been better if we made this change before solvers moved to this API 😄 buy hey...)
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.
Sorry, wrong file (I wanted to comment on the one above: crates/orderbook/src/dto/order.rs), there the field is user_fee
. Just want to make sure only our frontend depends on this field and can live without it.
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.
This is a similar change we had few weeks ago with solver_fee
: #2272 No major problems arose except shadow competition was down and alerter being down AFAIR.
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.
This time I would expect only shadow to be down because alerter is not deserializing user_fee
.
Fee::Static => self.order.user_fee, | ||
Fee::Static => { | ||
// Orders with static fees are no longer used, expect for quoting purposes, when | ||
// the static fee is set to 0. This is expected to be resolved with https://github.com/cowprotocol/services/issues/2543 |
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.
Is there anything blocking #2543 ? If not could we simply implement this now to combine the cleanups (I'm not sure there will be time scheduled for the follow up cleanup)
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.
Description
Fixes #2492
Related gnosis-solvers PR: gnosis/solvers#9
Will be merged next week - apparently we don't have enough solvers ready for this breaking change yet!
Changes
Removed field "user_fee" from auction endpoint - breaking API change.
Removed field "fee_amount" from solvers api - also breaking API change
How to test
Existing (updated) tests.