Conversation
|
Reminder: Please consider backward compatibility when modifying the API specification.
Caused by: |
MartinquaXD
left a comment
There was a problem hiding this comment.
I see what you are going for and overall it seems reasonable to me.
One thing that is not obvious to me is why we need a unique quote_id per solver. In terms of debugging it seems like using the same quote_id all sub-requests of the same POST /quote API call would be nicer and just for the fast path it doesn't seem necessary.
Is the motivation to make persisting quotes simpler for streamed quotes?
I like that this would move the id gaps that happen when fast path quotes don't result in actual executions into the quotes table which already has huge gaps.
Turning the regular and fast path settle requests into an enum or even into 2 structs for 2 entirely separate endpoints also makes sense. But that's orthogonal to the quote_id suggestion.
I think the key idea here is to decouple the solution caching from auction ids (at least for fast path).
Yeah, so for streamed quotes we want a different ID per response (so there is no confusion about which actual quote you are referring to in case there is a race between you consuming and ending the stream and us publishing new records). Agree, that the /settle refactor should be a separate PR. |
Description
Proposal for a slightly different fast path API. Instead of leaking the fast path feature (in particular the concept of a fake auction id + solver side chosen solution id) into all quote requests, I'd rather change the way we currently assign quote ids (one per request, only after the responses have been evaluated) to give each solver a unique quote id for each request (each request will have N id's, one for each solver).
This quote ID can be used on the solver side to cache fast past calldata, but also to inspect later on which request on their end caused a specific quote on a given order (better debuggability).
Fake auction ids only get generated in the autopilot now (even there, I'd prefer we use the quote id for differentiating between regular and fast path auctions).
I also suggest to change the
/settlerequest to make it more explicit that you may either be asked to settle a regular auction or a fast path order. I wouldn't be opposed to actually using a dedicated/settle_fast_pathendpoint neither so the correct logic needs to be explicitly implemented.Mainly looking for feedback to the general approach at this stage.