Open JANA-itsaishvili opened 2 months ago
update
Enabling cache in dev tools prevents the network requests, but this means you should still have an infinite render issue on the component level that is requesting the resource from the cache.
Also, it doesn't look like it's directly related to subscribe
call because I saw it complete on our other environment, but the requests for the svg are still loop infinitely.
Thank you for reporting this issue. We will reproduce it in our environment and will update you on our findings within the next few weeks.
We tested this scenario in our environment, and in our case, the call to the PBI logo image is made only once, even with the cache disabled.
Could you please provide more details to reproduce the issue.
Hi there,
A few things on this issue.
This constant request seems to be happening only on trial versions (with or without caching disabled).
Now about the issue itself, you're right, enabling cache prevents the image from being refetched, but this still is an issue. Most debugging is done with caching disabled, so we cannot debug the application without disabling the cache; otherwise, the requests will overwhelm the debugger eventually.
We recently ran into an issue embedding PowerBI in our react app where the iframe goes into an infinite loop loading the
PBI-logo.947f878993d21960993f.svg
resource.This request succeeds, but the iframe keeps requesting it indefinitely.
The only issue I can point to right now, is the
subscribe
endpoint is either cancelled or pending, and that could be triggering the internal state incorrectly:https://wabi-canada-central-redirect.analysis.windows.net/powerbi/refresh/subscribe
The initiator is
https://content.powerapps.com/resource/powerbiwfe/scripts/reportembed.externals.bundle.min.f9dbf5939d5b80fe9297.js
(the exact url is obviously not importat).The gist of the issue is even if the fault is somewhere on our end, the package should not spin up an infinite loop. The package should either wait for the
subscribe
call to complete, or throw an error and return an error state. We currently have no, or minimal control as far as I'm aware, of mitigating this issue.Here's two fragments of the network logs: