FlexMonster gets stuck in a loading state when loading data from some reports

It should be noted that this can be reliably replicated in some configurations that we have, but not others. From what we can tell, there is nothing especially different between them (Keys are the same, values are different albeit in the same format). This component was selected for it's flexibility but this issue is large enough that this has the potential to cause us to reconsider. We are hoping that it's something minor either you can correct or something we may be doing wrong that we can change.
We are using FlexMonster Pivot Table in a Blazor WASM application to show data retrieved from an API. The data is being loaded into the FlexMonster table as JSON returned from that Api, but sometimes the table gets stuck in a loading state. Looking at the events which get fired, we see the “loadingdata” event get triggered, but nothing after that (we see no error events in the dev tools console, and none of the components error events get triggered). We are using Flexmonster.Blazor 2.9.60 in .NET 7. Curiously, the issue only appears when the application is running in Azure. It does not appear when running locally, even when the app is built for a Release configuration. Thus, in case it is relevant, in Azure the app is running on a 64-bit Windows App Service, .NET 7 as mentioned.
The issue is in some ways similar to https://www.flexmonster.com/question/flexmonster-gets-stuck-in-a-loading-state-when-theres-a-delay-between-the-last-data-and-the-response-itself-closing/. Though that issue was marked resolved, it’s not clear if it was fixed in the Blazor integration. Notably in our case, the data is not being streamed by the backend, but returned in one chunk. And the amount of data being returned from our API seems not to matter (queries with both lots and little data being returned seem to work fine, except for this one set of parameters, which nearly always gets stuck).
We have tried a few experiments to attempt to isolate the problem, to wit:

• If the data is supplied by our API statically (i.e. without checking the database), everything seems to work fine
• However, if we check the DB to determine how many records to return, but then create those records from constant data in the API (so no actual records from the DB), the problem reappears. Thus it does not appear to depend on the specific details of the data that we are providing.
• We attempted to simulate the time delay of interacting with the database via Task.Delay but were not able to make the issue reappear using that approach.
• The issue is 100% reproducible with one set of parameters and rare with others, even though no actual database data is returned, and that is the only thing that changes when parameters change.

If it will be useful for the investigation, we can provide the data that causes the issue, however, it does contain customer information. Perhaps you can connect with us to discuss what you require from us.