-
Notifications
You must be signed in to change notification settings - Fork 28
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: [TD-1677] Add support for bids #2186
Conversation
☁️ Nx Cloud ReportCI is running/has finished running commands for commit a3ab266. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution ✅ Successfully ran 5 targetsSent with 💌 from NxCloud. |
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.
Just left a question
* the unsigned approval transaction, the typed order message for signing and | ||
* the order components that can be submitted to {@linkcode createBid} with a signature. | ||
*/ | ||
async prepareBid({ |
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.
question: do we intend to support bulk bid creation? If so would we prefer implement that method instead of this singular version? It hasn't been discussed as a requirement I don't think - but I suspect TT will ask for it.
I'm happy not having the bulk methods BTW, just wanted to flag it as a consideration.
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.
Discussed earlier with Steve. Summary: no clear usecase for creating bids in bulk, we can add it later if a partner asks for it.
const listingResultsPromises = Promise.all( | ||
orderIds.map((id) => this.apiClient.getListing(id).catch((e: ApiError) => { | ||
if (e.status === 404) { | ||
return undefined; |
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 this something we've always done specifically for 404's?
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.
When we're given an order ID, we don't know what order type it refers to. To retrieve the order, we hit each of the endpoints (/listings
, /bids'
) to retrieve the order. Given an order will only be of one order type, it will 404 for all but one of the endpoints. Further below we then check that all orders were found. This is an incredibly naive approach for now. The thinking is on-chain cancellation via the SDK isn't something we'll see often. We can invest in a less naive implementation should this assumption change.
Hi👋, please prefix this PR's title with:
breaking-change:
if you have introduced modification that necessitates immediate adjustments by this SDK's users to their applications, clients, or integrations to avert disruptions to existing features or functionalities.feat:
,fix:
,refactor:
,docs:
, orchore:
.Summary
Adds support to manage creation, cancellation and fulfilment of bids.
Detail and impact of the change
Added
To support bids on the zkEVM orderbook:
Orderbook.prepareBid
andOrderbook.createBid
functions to create bidsOrderbook.getBid
andOrderbook.listBids
functions to retrieve bids