Forum Discussion

Gllme's avatar
Gllme
New Member
1 month ago
Solved

Sharepoint lists mirroring issue

Hello, We currently face an issue with sharepoint lists mirroring in microsoft fabric and we have no clue what can happen because the error message is pretty useless : In fact, we are mirroring mor...
Mirroring
Need Help
  • Gllme's avatar
    Gllme
    1 month ago

    Hi Murtaza_Ghafoor​ ,

    Thank you for your message. 

    All the replicated lists contained many fields with complex ones aswell. Some were succeeded and others no so it was obviously not a problem with the types of the fields. They all seem to be accepted, even the most complex ones.

    Also I had already tried to clean and re-establish the connection dozens of times so there was another issue with the list I needed to find. As mentionned in my previous comment, it was a naming issue with the columns. The sharepoint lists replicating component was not able to manage different columns with the same name causing this kind of unexpected and not documented issue.

    Again thank you for your help, this is now solved.

v-csrikanth's avatar
v-csrikanth
Icon for Community Support rankCommunity Support
1 month ago

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.


Best regards,
C Srikanth
Community Support Team