Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
feat(rfq-api): add v2 contracts to rfq api endpoint [SLT-429] #3387
feat(rfq-api): add v2 contracts to rfq api endpoint [SLT-429] #3387
Changes from 3 commits
530a756
c15c47d
cf4ece0
981722c
e4867eb
b2cfa92
c1defaa
fc07ec5
6989ad2
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Check warning on line 397 in contrib/opbot/botmd/commands.go
Codecov / codecov/patch
contrib/opbot/botmd/commands.go#L397
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.
🛠️ Refactor suggestion
Refactor to reduce duplication between V1 and V2 contract fields
The
QuoterAPIServer
struct introduces separate fields for V1 and V2 contracts and role caches:Consider refactoring these fields to reduce duplication. One approach is to use a unified structure or map that can handle multiple versions, possibly by introducing a version key or encapsulating the contract and cache data together.
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.
@dwasse thoughts on this? Not sure if worth it, but I see that the new
roleContract
type could be potentially used here, as we only check roles anywayThere 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.
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.
My plan here was to keep these as separate fields temporarily while we support backwards compatibility, then remove the old fields. We could opt for a more generic approach if we want to support multiple versions down the line- do you think that will be the case?
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.
🛠️ Refactor suggestion
Reduce code duplication in contract initialization
The initialization code for v1 and v2 contracts is nearly identical, which could lead to maintenance challenges.
Consider consolidating the initialization logic into a helper function:
Usage:
Also applies to: 127-141
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.
Don't we need to derive the
useV1
flag from the request's origin/dest fast bridge addresses? Same applies to other casesThere 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.
Address type inconsistency in chain ID mappings
The FastBridge contract maps in the test config use
uint32
for chain IDs, but the implementation usesuint64
(seefastBridgeAddressMap
field). This type mismatch could cause issues in production code.Apply this diff to fix the type inconsistency:
Also applies to: 89-92