You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Description
Streamed quotes currently don't carry a quote ID making it impossible to
reuse them during order placement. This is problematic for a couple of
reasons
1. It increases the amount of quote requests we are sending to solvers
by a non trivial amount.
2. Re-quoting when the order is placed may mess with intended slippage,
market order classification and other things that are needed for a
reliable user and integrator experience.
3. Quotes without an ID can never receive a quote reward. If solvers
find a way to segregate the flow, they would be better off selectively
not responding to streamed quote requests, which are expected to become
the standard way for users to make the decision whether they want to
trade (therefore they need to be extra competitive)
# Changes
* Persist every quote candidate before it gets sent out in the stream
* Update the documentation and test cases around this.
## How to test
Existing tests
## Alternatives considered
https://app.notion.com/p/cownation/RFC-Quote-Persistence-for-Streaming-Quotes-38f8da5f04ca81a98f0fc016a3a37e81
contains two alternative AI generated options:
1. Mint the id at completion, send it as a final event.
2. Reserve one id up front, store the best under it (recommended).
The first option leads to having no quote id unless we wait for the full
timeout. This defeats the purpose of being able to quickly place orders
as soon as we have a quote that is "good enough". Especially with the
high deadlines suggested in cowprotocol/docs#638
I think we would not end up getting the final event in a good amount of
cases.
In the second option, if the client terminates the connection
prematurely there may be subjectivity around which quotes have been
received (and therefore what the client saw as "best").
The main downside of the approach in this PR is that it adds a small
amount of latency on the critical path (for the storage write), which in
the grand scheme of current quote latency is likely irrelevant. It will
also create more pressure on the DB, however since unused quotes are
very short lived I don't expect this to be a concern in practice. It
strikes me as the simplest approach therefore.
---------
Co-authored-by: Martin Magnus <martin.beckmann@protonmail.com>
0 commit comments