DM_GWPipeline_Gateway_MashupDataAccessError: "Timeout expired"

The error means the mashup engine hit its wait limit before the source returned all the rows, so the refresh was aborted mid-read. The HResult -2147467259 is the generic OLE DB "operation failed" code that surfaces when the source layer cannot deliver results in the allotted time, and it usually points to either a slow source query or M steps that broke query folding and forced Power Query to process rows locally.

Moving every table to SQL will not automatically solve it. What matters is that the work stays on the database side rather than getting pulled into the mashup engine. Open the M query, right-click the last applied step, and check View Native Query. If it is greyed out on your M-based table, folding broke somewhere, and the fix is to move that logic into a SQL view or the source query so folding is preserved end to end.

You can also raise the command timeout in the source options, but that only pushes the ceiling higher, it does not remove the underlying reason the refresh is slow.

If it solved your issue, kindly mark it as the accepted solution and give it a kudos.

Best,
Shai Karmani

Let's connect in LinkedIn

Hi Data-eng-81,

On your second question, moving everything to SQL won't make this go away, and it's worth knowing why before you spend a week on it.

There's no path that skips the mashup engine. The docs put it plainly: "Power BI semantic models rely on Power Query to access and retrieve source data." When you pick tables through a SQL connector, Power Query still generates M for them, you just never look at it. So a table you brought in "via SQL" and a table where you wrote M by hand go through the same engine and can both throw this. The M language isn't the culprit here, it's just the layer that reports the error.

On what the message means: the DM_GWPipeline_Gateway_ prefix is the gateway telling you it gave up waiting on the source. The -2147467259 is a generic failure code, it doesn't narrow anything down, so don't read much into it.

The number that usually matters is the command timeout, and it's set per connector rather than globally. On the connectors that expose it the advanced Command timeout option defaults to 10 minutes, and you can set it in the query itself:

Source = Sql.Database("yourserver", "yourdb", [CommandTimeout=#duration(0, 2, 0, 0)])

That's two hours. Swap the function for whichever connector you're on. I'd put it on the one slow table rather than everywhere, and treat it as buying time rather than fixing the cause.

Do you know which table it's actually dying on? Refresh history will tell you, and if it turns out to be the single M table then Shai_Karmani's folding point is where I'd go next.

Hi Data-eng-81​,

Based on the fact that the errors are consistently occurring at around the one-minute mark, I agree that the command timeout may not address the underlying issue in this particular scenario. The consistent timing does make concurrency or another service-side limitation worth investigating further.

As the Mashup Engine is involved in the processing path, it would be helpful to investigate whether there are any concurrency, resource, or capacity-related limitations being reached at that point.

I would recommend monitoring the refresh/query activity around the time of the failure and checking whether multiple operations are being executed concurrently. If the issue persists with the same one-minute pattern, raising a Microsoft support ticket may be the best next step, as Microsoft would be able to investigate the backend/service-side logs and confirm the exact cause.

Thanks,

Chaithanya.

Thankyou PauReis​ , Shai_Karmani​  for Addressing the issue.

Hi Data-eng-81​ shafiz_rn​   ,

As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided for the issue worked? or Let us know if you need any further assistance?

Regards,

Chaithanya

Hi v-kathullac, thanks for joining this discussion topic.

It's nice to know that i am on good path to solve this problem.

About capacity-related limitations,  the fabric capacity metrics report show that, at the time of failure, we didn't exceed the capacity limits.

I am going to try to improve the data refresh task on powershell, putting intern retry count on the same API calls, setting intervals between retries and, maybe, doing second API call if there area still some failures on data refreshs.

Nowadays, the gateway is on a server that is managed by one of our vendors. You said that "Microsoft would be able to investigate the backend/service-side logs and confirm the exact cause."

 Would microsoft need the logs of gateway-server-side too?

Thanks again. I am learning a lot with all comments

Hi Data-eng-81​,

As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided for the issue worked? or Let us know if you need any further assistance?

Regards,

Chaithanya