Openui5: Grid Table: Same Request Sent Over and Over Again

[boghyon]

URL (minimal example if possible):

embed.plnkr.co/ZnEpcAy5iKaukNXd

Given

• A grid table (sap.ui.table.Table) having rows aggregation bound with Northwind's /Customers. The service leverages server-side paging ("__next").
• Low number of Table's threshold.

Steps to reproduce the problem:

1. Open the above example page and wait until the preview panel is loaded.
2. Once the initial entries are loaded and the focus is set on the first row, press Ctrl + End to scroll to the end of the table. Do not scroll up afterwards.
3. Wait until any entries are loaded in the scrolled area... forever.

What is the expected result?

The table gets filled in the visible rows.

What happens instead?

• Requests are sent constantly and which never stops. I waited for around an hour until the browser ultimately crashed (Probably due to highly accumulated memory footprint).
• If table's enableBusyIndicator is set to true, the user cannot even scroll up anymore due to the busy indicator blocking all user interactions. Only when the user scrolls up until the previously loaded entries are visible, the table starts to get filled properly.

Any other information? (attach screenshot if possible)

I guess this behavior has something to do with the fact that the grid table involves both server- and client-side paging. Whether it's an anti-pattern or not shouldn't be a matter of this issue though.

^{Network trace showing the same request being sent over and over again}

[Shtilianova]

Hello @boghyon,
When I open embed.plnkr.co/ZnEpcAy5iKaukNXd the table data is not loaded. There is HTTP request is failing in the console. Could please provide a reproducible scenario.
Regards, Diana

[boghyon]

Hi @Shtilianova ,

Sorry for the incident. The Northwind service seems to have a problem with $batch requests lately. I turned it off with useBatch: false in the ODataModel settings (Edit: I wasn't setting https as the service protocol. See this comment). As the data are now retrievable in the plunk I shared, please try again to reproduce the scenario. Thank you.

[a-z-ivanov]

Hello boghyon,

I reproduced the issue and created an internal incident 1880473575. The status of the issue will be updated here in GitHub.

Regards,
Alex

[hugoinperson]

I have a similar issue but it's the other way around. I have a smart table bind with OData model. When use useBatch: false, the model will send out requests non stop.

[boghyon]

@hugoinperson FYI: The behavior I described above is reproducible regardless of whether useBatch is enabled or not. Are you also using the Northwind service? Or some other service that implements server-side paging ("__next" in response)? And which OData version?

[Thodd]

Hi guys,

So the endless loop should be fixed, as we have reworked the $skip/$top value calculation.

The Northwind responds with a set of max. 20 entries and a __next link, even though the request sent by the ODataListBinding contains a $top value of 60.
We know that this can happen, and the approach of the ODataListBinding is to ignore the __next link, and keep on sending consecutive requests with adapted $top and $skip values.
This is ok, since following __next links also ends up in multiple requests to satisfy the original data request by the table.

Though if you aim for a productive scenario the mix of our $skip/$top based paging and the Northwind's __next paging mechanism is suboptimal, as it will end up in multiple requests, which cannot be optimized as easily.

I would not advice to use such a mix in a real-life scenario.

Ideally you should just use a regular $skip/$top based paging.
The Northwind also offers other collections, which will fully respect $skip/$top, e.g.:
https://services.odata.org/V2/Northwind/Northwind.svc/Product_Sales_for_1997?$skip=10&$top=60&$format=json

At the moment we have no intention to implement a server-side paging based on __next links, but of course contributions are welcome and appreciated if anyone out there wants to tackle this.

BR,
Thorsten

[Thodd]

See also:
https://github.com/SAP/openui5/commit/2005ea049891ed661349524681fd2abbb89c1db3