Order lifecycle and ordering of OrderStream vs API requests

[KnackersYard]

It is known that the market data stream and the order stream have no guarantee of ordering. Is the same true for order lifecycle calls (effectively cancel and replace orders) via the API and the order stream. As an example:

Assume the latency between Bob (client) and BF is constant for all calls.

1). Bob subscribes to order stream;
2). Bob uses placeOrders (async);
3). Bob receives response;
3). Bob sees new orders in the order stream and updates cache;
4). Bob calls cancelOrders;
5). ....

At this point - is it possible the order stream emits the orders in their new cancelled state before the cancelOrder API returns? Do steps (2) & (3) have the same problem?

Is it possible the order stream has the orders in their new/changed state in it *before* the placeOrders/cancledOrders API call has returned?

Note the question disregards latency. This is purely about how BF internally handles the requests internally. Are they well ordered?

[BetfairDeveloperProgram]

Hi KnackersYard

At this point - is it possible the order stream emits the orders in their new cancelled state before the cancelOrder API returns? Do steps (2) & (3) have the same problem?

Is it possible the order stream has the orders in their new/changed state in it *before* the placeOrders/cancledOrders API call has returned?

Yes. While the two APIs are looking at the same internal components for updates, their responses are not synchronised in any way

Note the question disregards latency. This is purely about how BF internally handles the requests internally. Are they well ordered?

In coming bets are definitely ordered, so one can’t jump ahead of the other, but as for the feedback on a particular bet, i.e. API vs ESA response, we don’t sync that, as mentioned above.

Kind Regards

Neil

[KnackersYard]

Thanks. I suspected as much.

[KnackersYard]

Sorry, one more question. This makes it very difficult to confirm when an order in the order cache has been amended down and is showing the correct amended quantities.

Is it safe to use the delta in Size Cancelled? For example, let's say a working order has a Size=20 and Size Cancelled=5. I then cancel another 5. Is it safe to assume that when the order displays a Size Cancelled=10 via the order stream, it has been amended down. Does any *other* operation on BFs side affect the Size Cancelled amount, or is it only a call to cancelOrders?

You can see how if the API returns slower than the order stream, I may already have a Size=20, Size Cancelled=10 in my cache, and when API returns, I need to know whether I can add another 5 onto Size Cancelled for that order in my cache, or I know the cache is already up to date.

For a full cancel it is more obvious, as the order will move to an EXECUTION_COMPLETE status on the order stream. I assume?

[BetfairDeveloperProgram]

Hi KnackersYard

Is it safe to use the delta in Size Cancelled? For example, let's say a working order has a Size=20 and Size Cancelled=5. I then cancel another 5. Is it safe to assume that when the order displays a Size Cancelled=10 via the order stream, it has been amended down. Does any *other* operation on BFs side affect the Size Cancelled amount, or is it only a call to cancelOrders?

Yes, this is a safe assumption. updateOrders will also affect the size cancelled amount of an existing betId, as it's effectively a cancel of the full or remaining (if partially matched) bet amount at a new price, creating a new betId.

For a full cancel it is more obvious, as the order will move to an EXECUTION_COMPLETE status on the order stream. I assume

Yes, this is correct.

Let me know if you have any other questions.

Neil