order filled promise [feature]

[xgambitox]

Add a function that given an order Id it returns a transaction receipt (or any useful data from the order) once an order resolves as filled. If the order is not executed during its TTL, promise can be rejected.

This feature would allow integrators to implement use cases like updating user token balances once orders get filled, or display useful messages to user when order executes/fails.

[alfetopito]

Hey @xgambitox , thank you for the suggestion!

If I understand correctly, you are asking to have transaction info (if there's any) included in the cowSdk.cowApi.getOrder() response, correct?

For context, the cowApi right now is just a thin wrapper on top of https://api.cow.fi/docs/ and to get the trades for a given order another API call is needed.

We'll take your suggestion into account on our next planning session.

[xgambitox]

Hey @alfetopito, thanks for your response :)

Idea is more like having a function that resolves only once the transaction is in its final state, either by it resolving as a filled order (and returning some useful data) or by failing (and throwing an error).

Right now, a frontend would need to be polling the status of the order multiple times through the API until the state is changed to filled (Please point it out if there is already a way to do it). The feature would basically do this under the hood. This way, by just calling this function, a frontend can simply await for it to resolve, and be able to update users balances and display a message showing transaction was successful.

[alfetopito]

Please point it out if there is already a way to do it

Unfortunately no, polling is the only way currently and actually how we update the UI both on CoW Swap and the Explorer.

Idea is more like having a function that resolves only once the transaction is in its final state

You mean like a "forever awaiting" function until it either expires or is fulfilled?

[xgambitox]

You mean like a "forever awaiting" function until it either expires or is fulfilled?

Yes exactly. Internally it would just handle the polling, and resolve once status changes.

[xgambitox]

@alfetopito any follow up on getting this feature added ?

[alfetopito]

@alfetopito any follow up on getting this feature added ?

Unfortunately no updates.
We are fully committed to other features until the end of the year.

cc @anxolin

[xgambitox]

Unfortunately no, polling is the only way currently and actually how we update the UI both on CoW Swap and the Explorer.

Can you point me out what endpoint from the API you are using, so I can replicate it?

[alfetopito]

Unfortunately no, polling is the only way currently and actually how we update the UI both on CoW Swap and the Explorer.

Can you point me out what endpoint from the API you are using, so I can replicate it?

Here's how we do it on CoW Swap for the orders list endpoint, but the idea would be the same for a single order https://github.com/cowprotocol/cowswap/blob/main/src/cow-react/api/gnosisProtocol/hooks.ts#L8

And here how we fetch a single order with polling on the Explorer https://github.com/cowprotocol/explorer/blob/main/src/hooks/useOperatorOrder.ts#L95
It's a bit more convoluted as we also search for the same order in all networks which you might not need.

[anxolin]

I think is a great idea :)

BTW, were you planning to use it somewhere? If we know this is used for sure, we will be happy to implement it.

Also, if you want to give it a try, we accept contributions in the codebase, maybe you want to give it a shot?

[xgambitox]

@anxolin we use it in yearn's SDK, and was consumed by the now deprecated frontend. You can see the implementation we used at the moment here https://github.com/yearn/yearn-sdk/blob/main/src/services/cowSwap.ts#L106 .

Its a nice to have, but it can be achieved in the implementation side, so feel free to close issue

[anxolin]

Cool, thanks for pointing that out.
We recently improved a bit the SDK, and we wrote down a few ideas on a few things that could make it easier to use.

I included yours there, we'll see during SDK integration where are the friction points.
#117

Anyways, thanks for making the effort to give us some good ideas