Copy Data from Oracle (On-Premises Gateway) to Lakehouse Tables fails with 502 Bad Gateway — only on

[ImaneMeskine]

Environment:
- Source: Oracle Database
- Gateway: On-Premises Data Gateway — Local mode
- Destination: Microsoft Fabric Lakehouse (Tables, Replace mode)
- Activity: Copy Data (Data Factory in Fabric)

Issue Description

My pipeline copies data from an Oracle database to a Fabric Lakehouse through an On-Premises Data Gateway (Local mode). The pipeline runs successfully for most tables but consistently fails on specific tables with a 502 Bad Gateway error.

Key facts that make this difficult to diagnose:
- The failing tables already exist  in the Lakehouse and are fully accessible — I can run SELECT queries on them with no issue via the SQL Analytics Endpoint
- The pipeline was working fine before on these exact same tables — no changes were made to the pipeline, the source, or the gateway
- Fabric service is healthy — tested response time via Spark notebook: 0.18 seconds
- 0 corrupted Delta logs — verified all tables across the Lakehouse via Spark
- The error is on the Sink side (Lakehouse), not the Source (Oracle)
- `dataRead: 0` and `rowsRead: 0` — the pipeline crashes before reading a single row, during the initial write to the table path
- Copy duration before failure: 29 seconds only

---

Full Error Message

ErrorCode=LakehouseOperationFailed,
'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,
Message=Lakehouse operation failed for: An error occurred while sending the request..
Workspace: '2ce73336-d57b-4a4e-9768-4378b86fad0d'.
Path: '5f1deb97-7f66-4e80-b1f9-c442c314d99b/Tables/DE_RESNOW_COMMANDE/02a26636-0d31-4e44-a1a3-703072acde68.parquet'..,
Source=Microsoft.DataTransfer.ClientLibrary,
''Type=System.Net.Http.HttpRequestException,
Message=An error occurred while sending the request.,
Source=mscorlib,
''Type=System.Net.WebException,
Message=The remote server returned an error: (502) Bad Gateway.,
Source=System'

What I have already tried
- Retry = 3, Retry interval = 120 seconds → still fails
- Max degree of copy parallelism = 1
- Disabled V-Order on the Sink
- Verified Delta logs → 0 corrupted tables
- Verified Fabric response time → 0.18s, service healthy
- Confirmed failing tables are accessible via SQL Analytics Endpoint
- Gateway status shows Online in Fabric settings

Has anyone faced the same issue? Any lead or suggestion is welcome. Thank you!

[v-veshwara-msft]

Hi @ImaneMeskine ,

Just checking in to see if your query is resolved and if any responses were helpful.
Otherwise, feel free to reach out for further assistance.

Thank you.

[trivedisunita]

Hi @ImaneMeskine ,

The 502 isn't during data transfer. It happens during Replace-mode Sink initialization  when the pipeline tries to You can try this- write the first staging parquet file to that table path in OneLake, before Oracle is even touched.

In the ForEach activity settings, set In the ForEach activity settings, set Batch count = 1 (sequential execution). This prevents parallel writes from the same gateway hitting OneLake at the same time(sequential execution). This prevents parallel writes from the same gateway hitting OneLake at the same time.

or Add a Notebook activity before the ForEach to drop the problematic tables and clear any stale locks.

i hope this helps.

[v-veshwara-msft · Accepted solution]

Hi @ImaneMeskine ,
Thanks for reaching out to Microsoft Fabric Community,

From what you shared, the pipeline appears to be failing before any data is read (dataRead = 0), which typically means the gateway is unable to complete the initial handshake with the Fabric service. The "Failed to get service token (502)" message suggests that this request is going through the corporate proxy and not reaching the service successfully.

The relay-related error ("Invalid relays parameter") may also explain why some tables succeed initially and then subsequent ones fail within the same run. The gateway maintains a persistent connection using Azure Service Bus, and if that connection is interrupted or not fully established through the proxy, later iterations can fail.

Given this pattern, it would be worth checking the proxy configuration on the gateway machine. In particular:

* Ensure Azure endpoints are allowed or bypassed from the proxy --> specifically *.servicebus.windows.net, login.microsoftonline.com, *.frontend.clouddatahub.net, *.dfs.core.windows.net, and *.core.windows.net.

Steps on how to configure this in the gateway config files are covered here: Configure proxy settings for the on-premises data gateway | Microsoft Learn

* Confirm outbound ports required by the gateway are open (443, 5671, 5672, and 9350–9354). If the proxy is only permitting 80 and 443, Service Bus relay traffic on 5671/5672 will be dropped silently, which aligns with the relay error you're seeing.

Reference: Adjust communication settings for the on-premises data gateway | Microsoft Learn

* Check whether SSL/TLS inspection is enabled on the proxy, as this can interfere with gateway communication even when the proxy itself is reachable.

You can also run a diagnostics test from the gateway application (Diagnostics tab > Start new test) to validate connectivity to Service Bus endpoints. That output is usually helpful when working with the network team -- it lists exactly which ports and relay servers are failing.

As a temporary workaround, you can add a Wait activity between the Copy Data iterations inside your ForEach loop (30–60 seconds). This gives the gateway a bit more time to re-establish the relay connection before the next table starts, which may reduce how frequently the failures occur. It won't address the underlying proxy issue but can help keep the pipeline moving while that's being sorted out.

Hope this helps. Please reach out for further assistance.
Thank you.

[v-veshwara-msft]

Hi @ImaneMeskine ,

Just wanted to check if the response provided was helpful. If further assistance is needed, please reach out.
Thank you.

[tayloramy]

Hi @ImaneMeskine, 

If you go to the gateways and connections screen (settings menu at the top right -> manage gateways and connections) and click the test connection button on your connection, does it connect successfully?  

[ImaneMeskine]

Hi @tayloramy,

I tested the connection and it is successful. I got access to the gateway server and read the error logs. I copied some error lines because I couldn't export the full log. The gateway version is:

Erreur 1 

GatewayPipelineErrorCode=DM_GWPipeline_Gateway_MashupDataAccessError

Reason=DataSource.Error

Web.Contents failed to get contents from 'http://proxy-bur-int.bpa.bouyguestelecom.fr:3128/' (502): Bad Gateway

Erreur 2

Microsoft.DataTransfer.DIAgentClient.HostServiceException

Failed to get service token from ADF service

The remote server returned an error: (502) Bad Gateway.

Erreur 3

[DM.ServiceBusPortsTest] Error: Invalid relays parameter

[DM.Pipeline.GatewayPipelineTelemetry] Non-gateway exception encountered in activity scope

thank you in advance for your help.

[tayloramy]

Hi @ImaneMeskine, 

 Web.Contents failed to get contents from 'http://proxy-bur-int.bpa.bouyguestelecom.fr:3128/' (502): Bad Gateway

This is not an error from a copy data activity, but rather an error from Power Query, either a semantic model or dataflow gen 2 that is using the Web.Contents call. 

This is unlikely to be the root of your issue. 

[Lozovskyi]

Hello @ImaneMeskine ,

for the debugging purpose, could you please create dedicated pipeline having the only copy activity for these tables?

What might be a case, that tables rosult to the same name in lowercase (This is the lakehouse setup). For example 'Invoice' and 'invoice' will be treated as  'invoice'.

The other thing I've seen, impropreate type format. For some tables might be undefined precision, etc. So you can query table via lookup, but not copy.

this is how I check such cases

SELECT

    COLUMN_NAME,

    DATA_TYPE,

    DATA_PRECISION,

    DATA_SCALE,

    -- This helper column flags if the column will crash Fabric

    CASE

        WHEN DATA_TYPE = 'NUMBER' AND (DATA_SCALE IS NULL OR DATA_SCALE > 38) THEN 'CRITICAL'

        ELSE 'SAFE'

    END AS FABRIC_STATUS

FROM ALL_TAB_COLUMNS

WHERE OWNER = 'schema_name'

  AND TABLE_NAME = 'table_name'

ORDER BY 5 asc

[ImaneMeskine]

Hello @Lozovskyi,

Thank you for your response.

The query did not return any critical columns.

the IT administractor istall last version of the gateway, but the error persist.

[tayloramy]

Hi @ImaneMeskine, 

Can you share some screenshots of your pipeline and copy data activity so we can see the setup? 

I'm having no problems pulling data from Oracle databases. 

Can you also confirm what version your data gateway is, that the network port test passes, and that you have OCMT installed?  

[ImaneMeskine]

Hello @tayloramy,

Thank you for your response.

For my pipeline, I use a Copy Data activity within a ForEach loop.

The Copy Data works for some tables and returns the error mentioned before for the others.

source side:

destination side:

parameters:

I don't know how to get the version of the data gateway, but this is the gateway I use: authentication with a login and password type connection for Oracle.

Any help would be greatly appreciated. Thank you in advance!