Support engineers asking for browser traces for a *scheduled* gateway refresh ?!

[dbeavon3]

It is the end of 2024.  Why are professional support engineers at Mindtree asking for browser traces, when the scheduled refresh happened overnight?  I collected all the relevant logs that were needed a month ago.  The logs are related to a bug in the gateway that happens during a scheduled refresh.

I already shared the activity ID, request ID, and everything else.  

Now after a month has passed, a TA claims they can't report the bug to Microsoft unless we collect a browser trace.  A browser trace of what exactly?

They claim it is one of their minimal requirements to open a bug with Microsoft.  Why didn't they ask for this a month ago???  Now the refresh history that relates to this bug is long gone, since the service only preserves a few days of history.

Below are their minimal requirement for reporting a bug to Microsoft.  These requirements seem to exist for all types of bugs, even for a bug that has nothing to do with the web browser.  I had thought they abandoned the requirement for these pointless browser traces many years ago.  

Note that there is no issue in the browser to begin with

I just thought I'd put a copy of this information here, for those of you who try to report Power BI bugs in 2024 and beyond.  It is very unintuitive that anyone would need a browser traces for an overnight scheduled job, and it is typically something that the engineers themselves won't think to gather, until it is too late.

[rajendraongole1]

Hi @dbeavon3 -Unfortunately, this sort of situation does happen when dealing with large-scale service providers like Microsoft, where protocol adherence may sometimes overshadow practical relevance. Hopefully, by escalating the issue or directly questioning the requirement, you can get a more productive path forward.

You could escalate the issue internally at Mindtree, pointing out that the request is being made late and that the history is no longer available.Clarification: Request explicit clarification as to why a browser trace is needed for a gateway issue that occurs in a scheduled refresh (which typically runs server-side without any client browser involvement).

Even though the issue happens during a scheduled refresh, there may be assumptions made by the support team that any client-side interactions (like opening the report or any metadata being refreshed in the browser) are relevant. Some gateway or authentication issues, particularly if there’s an element of browser-based Power BI Service involved (e.g., any post-refresh report loading), might introduce errors that can only be observed through a browser trace.

[dbeavon3]

Hi @rajendraongole1 

One of the reasons they had overlooked the trace the first time around is probably because the primary engineer was not interested in that HAR file themselves.  They were only interested in meaningful details related to the scheduled refresh.  ... The browser trace is a pointless excercise. 

Long ago I had the initiative to gather these pointless browser traces myself during these cases; but it always seemed like an insult to the Mindtree engineer, since they know as well as I do that the browser trace is useless (assuming you have the details that are otherwise presented in the browser, like the root activity ID and error message).

For my current incident, the TA (finally) got involved after a month.  The request for the browser traces just seemed like a stall tactic to me, and was very bothersome.  The TA knows as well as anyone that the HAR file is pointless.  It bothers me that he needs yet another stall tactic at this point, given the entire support case has not moved forward in the past month.

FYI, It was more common to gather the HAR files in the past (three years ago).  But I thought they had stopped requiring it for the sake of a Microsoft IcM.  So I stopped initiating the gathering of the HAR about two years ago.  ... However in light of this current case, I'll go back to initiating this pointless excercise. We can make make sure that the Mindtree engineer gathers these silly traces at the very start of every incident, no matter how pointless that may seem.

It really bothers me that the refresh history of the service only captures a few dozen refresh occurrences.  It almost seems like Microsoft is enabling Mindtree to use this as a reason to throw out some of their cases (ie. "so sorry, we have lost the ability to access your back-end logs, please open a new case next time....")