[25.x][PowerBI] Avoid race condition when setting filters for a loaded report before it's rendered #2546
+6
−4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
In the Power BI embed addin, we allow AL code to set report filters through the add-in.
How that works in our current implementation is:
We open the AL page hosting the addin
Once the addin is ready, we Embed the Power BI report
Once the report is loaded, we set the initial filters
The filters can then be changed by AL code
The issue here happens in step 3, because we set the initial filters after the report is loaded and before it's rendered. In some cases and depending on the machine performances/internet connection/browser/Power BI service load, there can occur a race condition between the report being rendered and the filters being applied.
This is more visible when using the action "Expand Report", because the initial filter will always be in place there, and in my tests in SaaS, around 1 time every 3 times the filter fails to apply (but it's still listed under the Power BI filters within the addin). When testing on my local development environment, I could repro this only by introducing a delay before applying the filters, small enough to collide with the rendering.
To fix this race condition, with this PR we wait for the report to be rendered for the first time before raising the Report Loaded event (which causes AL to send the filters ahead). Notice that loaded happens only once per report, whereas rendered happens after any change in the UI happens, including setting filters, so we need to turn the event off after the first occurrence to avoid infinite loops.
Work Item(s)
Fixes AB#560727