Sharepoint lists mirroring issue

Hi Gllme​ 

Thanks for the screenshots, they help. The Internal system error message is a generic server-side error, and unfortunately querying the Eventhouse won't return a longer ErrorMessage than the one you're already seeing.

The useful field here is OperationName in the MirroredDatabaseTableExecution monitoring table it shows which stage each table reached before it stopped.

Start with this:
MirroredDatabaseTableExecution | where Timestamp > ago(7d) | where ItemId == "<your mirrored item ID>" | summarize StagesReached = make_set(OperationName), Rows = sum(ProcessedRows), LastSeen = max(Timestamp) by SourceTableName | order by SourceTableName asc

If the failing GI_* lists stop at ReplicatingSchema, the break is at schema read. If they reach Snapshotting and then FailTable, it's the initial data load.

Also worth making explicit what your first screenshot already shows: per the documentation, an empty Last completed value means the table isn't yet mirrored. Combined with Rows replicated = 0, your GI_* lists have never completed an initial run — so this is initial load failing, not incremental replication drifting.

The naming split is your strongest clue. COI_* replicates and GI_* doesn't, under the same mirrored item and the same capacity. Compare one working list against one failing list:

• Are the GI_* lists on a different SharePoint site or site collection?
• Are any of them actually Document Libraries rather than lists? The documentation notes Document Library data is surfaced in OneLake through shortcuts rather than being replicated, so it follows a different path.
• Do they differ in columns or data volume?

As an isolation test, mirror one failing GI_* list on its own into a new mirrored item. If it fails alone, we can focus on that list or site rather than the whole item.

One thing not worth chasing: special characters in column names are documented as supported, via Delta column mapping.

If the single-list test still returns only SystemError, I'd open a Microsoft support ticket with the ArtifactId, SequenceNumber, UTC timestamps, workspace and tenant details, and the monitoring log output those are correlation identifiers the service team can match against backend telemetry. SharePoint List mirroring is still in preview, so it's worth checking the known issues list first too.

• Mirrored database operation logs
• Monitor mirrored database replication
• Mirroring SharePoint List (preview)

Best regards,
C Srikanth
Community Support Team

Hi Gllme​ 

We would like to inquire whether have you got the chance to check the solutions provided by other users in community to resolve the issue. We hope the information provided helps to clear the query. Should you have any further queries, kindly feel free to contact the Microsoft Fabric community.

Hi v-csrikanth​ ,

First of all, thank you for your help and your time, your message helped me a lot to find out what was going wrong.

In the eventhouse, each failing mirroring list (GI_*) was producing 2 rows with 2 different OperationName : 1 Replicating Schema and 1 FailTable. So I supposed the error was coming from the schema.

As you told me it cannot be an issue with special characters I tried to find out which column was causing the issue. Maybe a specific data type ? But every data type used in the GI_* lists was also used in the COI_* ones so it cannot be linked to datatypes.

Previously I have already find out that a missing mandatory value in a sharepoint list was causing that type of issue aswell so I fixed every missing mandatory values and I started removing columns 1 by 1 to find the misconfigured one.

Finally, I got it, the issue was caused by 2 different columns with the same name which is unfortunately permitted in a sharepoint list but forbidden for the Fabric replication component (which seems quite obvious though as it is also forbidden in a data table).

I have also previously suspected the number of columns as there are around 40 columns in the COI_ lists and more than 80 in the GI ones but everything seems good here :)

Again, thank you for your help and I hope this can help other people aswell in the future.

Hi Gllme​ 

Thank you for coming back and documenting the outcome so thoroughly that's genuinely valuable, and it will help the next person who hits this.

Root cause: two columns with the same name in the SharePoint list. SharePoint permits this, but the Fabric replication component doesn't, and the result is a generic Internal system error rather than a useful message.

Worth knowing why SharePoint allows it: every column has both a display name and a fixed internal name. The UI blocks a duplicate display name at creation time, but if a column is renamed and a new one is later created using the original name, you end up with two columns that look identical to users while their internal names still differ. To check, edit a column and read the Field= value in the URL.

The diagnostic path that worked, for future reference: OperationName in the monitoring logs showed ReplicatingSchema followed by FailTable meaning the failure was at the schema stage, before any data was read. That's what narrowed it to a column definition problem rather than data volume or data types.

Also useful that you ruled out column count ~40 columns in the working lists versus 80+ in the failing ones, with no impact.

Best regards,
C Srikanth
Community Support Team

Gllme​ 

I would simply compare the schema of SharePoint lists those are succeeding and the one are failing and try to compare it’s schema, if failed lists have some unusual schema like

Person, Lookup, Managed Metadata, multi-value Choice, Attachments, or complex SharePoint fields

that could be the reason for the failure.

I would also try a clean and re-establish the connection again.

For one failed list:

• Open the Fabric Mirroring item.
• Go to Configure replication.
• Remove/uncheck the failing SharePoint List.
• Save.
• Wait a few minutes.
• Add the same list again.
• Start/refresh mirroring.
• Reseeding/re-enabling affected objects is a documented troubleshooting approach for this class of generic Mirroring error.
  Generic Mirroring Link Error given below:
  

  Error in Mirrored google Big query | Microsoft Fabric Community
  
  If this helps, ✓ Mark as Kudos | Help Other

Hi Gllme​ 

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. And, if you have any further query do let us know.

Thank you.