Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PowerBI] Avoid race condition when setting filters for a loaded report before it's rendered #2526

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

encimita
Copy link
Contributor

@encimita encimita commented Dec 12, 2024

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:

  1. We open the AL page hosting the addin
  2. Once the addin is ready, we Embed the Power BI report
  3. Once the report is loaded, we set the initial filters
  4. 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#556391

@github-actions github-actions bot added this to the Version 26.0 milestone Dec 12, 2024
@encimita encimita marked this pull request as ready for review December 13, 2024 16:07
@encimita encimita requested a review from a team as a code owner December 13, 2024 16:07
@encimita encimita requested review from dawidwoz and mynjj December 13, 2024 16:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants