Forum Discussion
Microsoft.Mashup.Engine.Interface.ResourceAccessAuthorizationException - need English translation
Can someone give me a plain-English translation for the following?
Error Code: Mashup Exception Data Format Error, Error Details: Couldn't refresh the entity because of an issue with the mashup document MashupException.Error: Failed to insert a table., Underlying error: Parquet: class parquet::ParquetStatusException (message: 'Unknown error: Microsoft.Mashup.Engine.Interface.ResourceAccessAuthorizationException: Exception of type 'Microsoft.Mashup.Engine.Interface.ResourceAccessAuthorizationException' was thrown.
at Microsoft.Internal.ParallelAppender`1.Dispose()
at Microsoft.Mashup.Common.StreamExtensions.<>c__DisplayClass11_0.<AfterDispose>b__0()
at Microsoft.Mashup.Common.StreamExtensions.NotifyingStream.HandleCallback()
at Microsoft.Mashup.Common.StreamExtensions.NotifyingStream.Close()
at ParquetSharp.IO.ManagedOutputStream.Close(String& exception)') Details: Reason = DataFormat.Error;Message = Parquet: class parquet::ParquetStatusException (message: 'Unknown error: Microsoft.Mashup.Engine.Interface.ResourceAccessAuthorizationException: Exception of type 'Microsoft.Mashup.Engine.Interface.ResourceAccessAuthorizationException' was thrown.
It happens on a GEN2 dataflow which is simply sending its outputs to file storage at the service (parquet).
The mashup normally runs in an hour and a half (with a P1 limit of five hours). Image below. No single step takes anywhere close to an hour.
.. However it appears that in the chance that one of these step takes longer then an hour, then the GEN2 dataflow will fall over and die:
There are multiple issues underway here. Firstly, I don't know of a valid reason (on our side) why the GEN2 DF was taking so long today. I'm certain the fault was at the PBI service itself, and I have no visibility to investigate because Microsoft has never shared our workspace logs with us.
Secondly, the code should not be designed to fall over, while closing the ParquetSharp.IO.ManagedOutputStream. It seems like a very obvious bug to do an authorization check while closing a stream. If a last minute authorization check needs to happen, then a fresh oauth token should be used.
As a side, I've had numerous bugs popping up this year with the oauth-token-refresh behaviors in Power BI. You wouldn't think this sort of thing would be so difficult, but this appears to be yet another place where Microsoft seems to be trying to use expired tokens to connect to remote services and resources.
If anyone understands the error, or has ideas for investigating it a bit more deeply then please let me know. Hopefully it won't become a common thing, but the particular GEN2 DF has only been running for about a week. This tech seems very fragile, as of now..
3 Replies
Wonder if it has to do with the auth token expiring and the refresh token not being requested
Hi, dbeavon3
Your question looks like the system encountered an authorization issue while trying to insert a table into a Parquet file during a dataflow process. This might be due to an expired or invalid access token.
- When using OAuth2 credentials, the gateway currently doesn't support refreshes longer than an hour. These refreshes will fail because the gateway cannot support refreshing tokens automatically when access tokens expire, which happens one hour after the refresh started
Please refer to the following links hope it helps.
Data Factory limitations overview - Microsoft Fabric | Microsoft Learn
Microsoft.Mashup.Engine.Interface.ResourceAccessForbiddEnexception - Microsoft Community
Best Regards,
Community Support Team _Charlotte
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.
Thanks for the tips Anonymous
While I understand that data factory pipelines may still be restricted to an hour, that should NOT apply to "GEN2" dataflows. There have been some blogs and docs which were generated this year to say that GEN2 dataflows are no longer impacted by oauth expirations after an hour.Customers expect our dataflows to run for five hours on dedicated capacity. A failure after an hour seems silly, especially while *closing* a stream (ManagedOutputStream.Close).
Note that the code is pointed directly at the "Mashup" logic from the core gateway PG:
Microsoft.Mashup.Engine
Microsoft.Mashup.CommonWhat would you suggest for next steps? I've tried to report bugs like this to the gateway PG and they are totally uninterested in hearing from their customers. They usually require us to spend a whole month in meetings with Mindtree before they are willing to receive an ICM or look at an obvious bug in their PBI dataflows. This one should be easy to repro, assuming someone on the PG wanted to fix it.
