Forum Discussion
Fabric Mirrored Database Change Feed Eventstream source connector stuck in a restart loop
I tried using the database change feed with EventStream to trigger a notebook on changes, but ran into a problem. Has anyone else successfully used the change feed with an EventStream? Any advice on solving the error below?
We built open mirroring (Mirrored Database) → Delta Change Data Feed → Eventstream
Mirrored Database Change Feed source → Filter operator (keep specific table) → Activator.
The Change Feed source connector repeatedly logs, in the Eventstream Runtime logs:
Warning Validate connector: '<connector-id>'.
Warning Connector runtime config validation is unhealthy. The connector will be restarted.
Failed reason: Connector validation failed, please retry the request.
This recurs several times per hour. Because each restart appears to re-read from the snapshot rather than resume from a committed offset, the stream is continuously flooded with duplicate read events, all carrying the same (latest) EXPORT_TIME, arriving hours after the source batch was actually processed.
2026-07-13 03:59:39 — "Connector runtime config validation is unhealthy. The connector will be restarted."
2026-07-13 11:18:16 — "Failed reason: Connector validation failed, please retry the request."
2026-07-13 11:20:07 — "Connector runtime config validation is unhealthy. The connector will be restarted."
2026-07-13 12:19:35 — "Failed reason: Connector validation failed, please retry the request."
2026-07-13 12:21:15 — "Connector runtime config validation is unhealthy. The connector will be restarted."
5 Replies
Thank you for your response and ideas!
The Mirrored database is active and syncing without replication errors, and the delta change feed is enabled. I created a very basic task as you described and got that same error. This is an open mirror using parquet files.
Unfortunately, I can't open a request directly with Microsoft Fabric Support. I asked our MSP support provider to open a support request and provide them with all the information, and they said that because it's in preview, Microsoft will not accept issues on this. Their suggestion was to post here. That seems odd because how could Microsoft fix this and get to production if you can't report issues?Hi philhansen,
Thanks for testing that and for clarifying the support situation.
Since the same failure occurs in a newly created Eventstream containing only the Mirrored Database Change Feed source, I think you have isolated this away from the Filter and Activator. The mirrored database is healthy, Change Feed is enabled, and the minimal reproduction still fails, so this now looks specific to the source connector or its interaction with the Open Mirroring implementation.
I understand your frustration regarding the support route. Because the connector is currently in Preview, it is not covered by the same production guarantees as a generally available feature. Given that your MSP has advised that they cannot raise it through their normal Microsoft support channel, posting a clear reproduction here may currently be the most practical escalation path available to you.
To make the report as actionable as possible for the Fabric team, I would add the following details to the thread, provided none of them expose sensitive information:
- Fabric capacity region
- Eventstream ID and connector ID
- The approximate restart interval
- Relevant runtime-log timestamps
- Confirmation that the issue occurs with a single small table
- Whether all mirrored tables are affected
- Whether the same EXPORT_TIME value is replayed after every restart
- The Open Mirroring metadata format and file-generation pattern being used
You could also verify through the mirrored database definition that enableDeltaChangeDataFeed is stored as true, rather than relying only on the portal setting. That would give Microsoft one more concrete data point and remove another possible configuration question.
At this point, I do not see a documented customer-side fix for this specific validation loop. I would also avoid treating downstream deduplication as the solution, because it may protect the destination from duplicate events but would not resolve the connector repeatedly restarting and replaying its snapshot.
Hopefully someone from the Fabric product team can review the reproduction and runtime details here. Please keep the thread updated if you receive any further information from your MSP or Microsoft.
Here are answers to questions I can answer.
Fabric capacity region - North Central
Eventstream ID and connector ID - f2657fb3-4d11-46fc-be83-159e49fc3155
The approximate restart interval - Restarts Hourly
Relevant runtime-log timestamps - Created new test eventstream 8/3/2026 13:20.
Confirmation that the issue occurs with a single small table - Mirrored Database Change only allows all tables.
Whether all mirrored tables are affected - Yes, have tested with multiple mirrored databases.
Hi ,
I searched for this specific runtime-validation message but could not find a documented Microsoft fix or an existing known issue for it.
From the logs, the Mirrored Database Change Feed source appears to be failing its recurring runtime validation and then restarting. Since each restart seems to replay snapshot data, I would first isolate whether this is happening independently of the Filter and Activator.
I would create a new test Eventstream containing only:
Mirrored Database Change Feed source → one small table
Leave out all transformations and destinations initially. If the connector still logs: Connector runtime config validation is unhealthy then the issue is likely isolated to the source connector, its configuration, or the Preview service itself. If it remains stable, add the Filter and Activator back one at a time.
I would also verify that:
- The mirrored database currently shows as actively syncing without replication errors.
- Delta Change Data Feed remains enabled.
- The issue occurs with one small table in a newly created Eventstream, rather than only in the existing Eventstream.
Could you confirm which mirrored source type you are using and whether the minimal Eventstream produces the same restart loop?
Since the connector is currently in Preview and there does not appear to be a documented resolution for this exact validation error, I would raise a Fabric support request if the minimal test also fails. I would include the workspace ID, Eventstream ID, capacity region, connector ID, runtime-log timestamps and details about the repeated snapshot events.
