Azure Cosmos DB Mirroring in Fabric – Internal System Error, 0 Rows Replicated (STG vs PRD)

[DiegoF93]

Hello community,

We are experiencing a persistent issue with Azure Cosmos DB → Microsoft Fabric Mirroring and would like to understand if others have encountered this and how it was resolved.

Context

• Source: Azure Cosmos DB (SQL / NoSQL API)
• Target: Microsoft Fabric – Mirrored Database (OneLake)
• Capacity: F4 (stable, not saturated)
• Region: East US
• Setup works correctly in PRD, but fails in STG

Issue

After stop/start cycles (including automation via API), the mirroring enters an unrecoverable state:

• Status: Running or Running with warnings
• Rows replicated: 0
• “Last completed” never updates
• No new data is reflected

Error observed:

Internal system error occurred.
ArtifactId: 2b8f2d06-5c02-44a9-871d-5321214ef14d
SequenceNumber: <n>
ProcessedRows: 0
ProcessedBytes: 0

What we have already tested

• Recreated mirroring multiple times
• Created new connections
• Tested different containers
• Tested with new containers and simple documents
• Restarted capacity
• Verified pipelines can read Cosmos data (works correctly)
• Compared with PRD (same setup works fine)

Key observations

• Issue only occurs in STG environment
• Cosmos DB is healthy and accessible
• Pipelines work, but mirroring always fails
• Appears related to Change Feed or internal mirroring state
• Mirror does not recover even after restart or recreation

Questions

1. Has anyone experienced this Internal system error / SequenceNumber issue?
2. Is this a known limitation or bug in Fabric mirroring?
3. Is there any way to reset or recover the mirroring state without recreating everything?
4. Is recreating the Cosmos account the only reliable solution?
5. Any best practices to avoid this when using automated start/stop?

Any insights or similar experiences would be greatly appreciated.

Thank you!

[Tamanchu · Accepted solution]

Hi @DiegoF93,

Note: This response was enhanced with the assistance of an AI tool. The information has been verified against the official Microsoft Fabric documentation.

This pattern mirroring stuck at "Running" with 0 rows and a frozen "Last completed" after a stop/start cycle is a known transient state with Cosmos DB mirroring. The root cause is usually a stale internal Change Feed checkpoint that doesn't reset cleanly on restart.

A few targeted things to try:

1. Delete and recreate but wait 10+ minutes before recreating
The internal Change Feed lease container in Cosmos needs time to fully release after a stop. If you recreate too quickly, the new mirror picks up a corrupted lease state. Wait at least 10 minutes after deleting before creating a new one.

2. Check the Cosmos DB Change Feed lease container
Fabric Mirroring uses the Cosmos DB Change Feed internally. Go to your Cosmos account → Data Explorer → look for a container named _fabric_mirror_leases or similar. If it exists and has stale documents, delete them before recreating the mirror.

3. STG vs PRD check if it's a network/firewall difference
Since PRD works but STG doesn't, verify that STG's Fabric capacity has the same network access to Cosmos DB (no VNet restrictions, IP allowlist includes Fabric East US egress IPs).

4. Open a support ticket with the ArtifactId
The Internal system error with a specific ArtifactId means the error is logged server-side at Microsoft. File a support request referencing that ArtifactId the Fabric team can trace the exact failure from their telemetry.

Docs: Troubleshoot Fabric mirrored databases 

[v-aatheeque · Accepted solution]

Hi

Have you had a chance to look through the responses shared earlier? If anything is still unclear, we’ll be happy to provide additional support.

[Tamanchu · Accepted solution]

Hi @DiegoF93,

Note: This response was enhanced with the assistance of an AI tool. The information has been verified against the official Microsoft Fabric documentation.

This pattern mirroring stuck at "Running" with 0 rows and a frozen "Last completed" after a stop/start cycle is a known transient state with Cosmos DB mirroring. The root cause is usually a stale internal Change Feed checkpoint that doesn't reset cleanly on restart.

A few targeted things to try:

1. Delete and recreate but wait 10+ minutes before recreating
The internal Change Feed lease container in Cosmos needs time to fully release after a stop. If you recreate too quickly, the new mirror picks up a corrupted lease state. Wait at least 10 minutes after deleting before creating a new one.

2. Check the Cosmos DB Change Feed lease container
Fabric Mirroring uses the Cosmos DB Change Feed internally. Go to your Cosmos account → Data Explorer → look for a container named _fabric_mirror_leases or similar. If it exists and has stale documents, delete them before recreating the mirror.

3. STG vs PRD check if it's a network/firewall difference
Since PRD works but STG doesn't, verify that STG's Fabric capacity has the same network access to Cosmos DB (no VNet restrictions, IP allowlist includes Fabric East US egress IPs).

4. Open a support ticket with the ArtifactId
The Internal system error with a specific ArtifactId means the error is logged server-side at Microsoft. File a support request referencing that ArtifactId the Fabric team can trace the exact failure from their telemetry.

Docs: Troubleshoot Fabric mirrored databases 

[v-aatheeque · Accepted solution]

Hi

Have you had a chance to look through the responses shared earlier? If anything is still unclear, we’ll be happy to provide additional support.

[v-aatheeque · Accepted solution]

Hi @DiegoF93 

We wanted to follow up to check if you’ve had an opportunity to review the previous responses. If you require further assistance, please don’t hesitate to let us know.