I was asked by my colleague with such a question: sometimes we can observe there are some odata request with cancelled status in Chrome development tool:
This cancelled OData request could be generated by double clicking the search icon in Master list:
Some colleague explained that suppose there are two OData request sent with the same destination url to backend within a very small time window, then the first request will automatically be cancelled.
I am not satisfied with this answer which I have two doubts:
1. What is the exact size of the time window which could be regarded as “small”? Within 1 seconds? 1 millisecond?
2. Which component will “automatically” cancel the first Odata request? The UI5 library in the frontend or the gateway in the backend?
In order to simply prove above statement is not so accurate, I write some small test code to send a bundle of OData request with same url to read a given opportunity in a for loop, via synchronous and asynchronous way separately.
The test result shows that none of them is cancelled. Both of them could be successfully finished regardless of synchronous and asynchronous mode.
So how to continue the analysis of this cancel behavior? Hover the mouse to the Initiator and then the complete callstack for the cancelled OData request is displayed. Click ODataListBinding.js where the OData request is sent:
Search by keyword abort and find the function abortPendingRequest.
Set a breakpoint on it. Double click the sort icon, breakpoint will be triggered.
From the source code we can know that it is OData implementation which deliberately perform the cancellation of any pending request before it sends out a new filter request.
The reason of this design could also be found in the comment of source code: the filter / sort operation will lead to the context change so previous pending request is not relevant any more – it is ok to cancel them.
Finally the abort of request is implemented by abort method of XMLHttpRequest.
The implementation logic of ODataListBinding.filter could simply be concluded as below figure:


Perform the source scan on keyword abortPendingRequest, and the result shows that the logic of pending request evaluation is only available in operations which will lead to context change, that is, the API sort, filter and refresh provided by ODataListBinding.
Let’s use a small test to finish this blog.
When I change the OData request in my small example from reading a given Opportunity to perform a filter request, the previous 9 request are still not cancelled simply because none of the mentioned sort, filter and refresh API are called.
The result in network shows that all 10 requests are handled successfully.
And when I make local changes on the filter icon event handler of the master list: now every time the filter is clicked, 10 requests are sent simultaneously:
This time all previous nine requests are cancelled as expected:
The test code to send OData request within a loop could be found from my github.

Further reading – A list of my debugging posts

I have written a collection of blogs which contains my experience how to resolve some issue or figure out the logic of UI5 framework under the hood via self-debugging. See a list below:
To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply