Skip to content
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: Add some subscription logic to the cow API. #2125

Closed
marcovc opened this issue Dec 5, 2023 · 4 comments
Closed

feat: Add some subscription logic to the cow API. #2125

marcovc opened this issue Dec 5, 2023 · 4 comments

Comments

@marcovc
Copy link
Contributor

marcovc commented Dec 5, 2023

Problem

Given that notify stopped notifying about the rank in the co-located setup, to be able to monitor if a solver wins an auction we need to query the cow API. For this, we need to know the batch id, which is I suppose is only provided in the solve() call.

In order to keep the monitoring logic separated from my solver, I have a dedicated process that just monitors the competition, and stores whatever is needed. This process does not get a notify call, so it does not know the latest auction id.

Suggested solution

Maybe there is a way I am not aware of, but would be nice if I could just subscribe some websocket to be informed of new auctions, or at least some endpoint I could keep polling.

Alternatives considered

An alternative is to listen to the smartcontract submission events, which gives a txhash that can also be used to query about the settlement. But unfortunately, querying with a txhash is only possible 30 minutes or so after the settlement happened, which does not provide an updated monitoring.

@fleupold
Copy link
Contributor

fleupold commented Dec 6, 2023

Don't we already populate the auction id on each instance we send to solvers (code)?

With this id you should be able to query https://api.cow.fi/docs/#/default/get_api_v1_solver_competition__auction_id_ to get your ranking.

@marcovc can you confirm this is working and close this issue in that case?

@marcovc
Copy link
Contributor Author

marcovc commented Dec 6, 2023

Right, the issue is that then either the solver needs to also do the monitoring (which I think is a bad idea given that the solver is the "mission critical" part), or the solver needs to tell an external container responsible for monitoring that a new auction id was generated (which is what I am now doing, but seems like a unnecessarily convoluted path).

@fleupold
Copy link
Contributor

fleupold commented Dec 6, 2023

I see. Would #1945 solve the issue? Adding websocket support to our API seems like a big endeavour that I don't see happening in the near future.

@marcovc
Copy link
Contributor Author

marcovc commented Dec 6, 2023

That would solve it indeed. I suppose you guys are used to solvers continuously polling the endpoints anyway :)

Thanks

@marcovc marcovc closed this as completed Dec 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants