Forum Discussion
Event Stream Disabled In Main Branch But Enabled In Sub-Branch Using Git Integration Draining CUs
Hello scca,
We understand the scenario you’re describing. To clarify directly:Fabric Git integration does not attempt to infer branch intent (main vs feature branch) or mirror runtime state. Git sync applies the item definition only, and the target workspace runtime independently evaluates execution state. This is consistent across environments, regardless of whether the workspace is temporary or long lived.
When an Eventstream appears active after sync, Fabric is not assuming it should run because it was inactive elsewhere; rather, execution state is not carried over at all. The runtime in the target workspace evaluates the definition without inheriting prior execution decisions.
This differs from pipelines, where enabled/disabled activities are part of the definition itself. For Eventstreams, start/stop is handled by the workspace runtime and capacity scheduler, not embedded in the versioned artifact. For that reason, Git does not persist or enforce the Active/Inactive state.
From a support standpoint, this is the current and expected behavior in Fabric:
- Git versions what the Eventstream is
- Each workspace independently controls whether it executes
If you’d like this behavior to be considered differently, you may share your scenario in the Fabric Ideas forum: https://community.fabric.microsoft.com/t5/Fabric-Ideas/idb-p/fbc_ideas, where product feedback is reviewed by the engineering team.
For your reference: https://learn.microsoft.com/en-us/fabric/real-time-intelligence/event-streams/eventstream-cicd
Best regards,
Ganesh Singamshetty.
Hello scca,
We hope you're doing well. Could you please confirm whether your issue has been resolved or if you're still facing challenges? Your update will be valuable to the community and may assist others with similar concerns.
Thank you.
Hey, Ganesh. I don't think the issue is resolved and the challenge remains the same: if the main branch has an evenstream toggled "inactive", it just doesn't make sense to have a feature branch magically turn that
"active". Based on your response, maybe the solution is to not have active/inactive toggle handled as a runtime execution state and instead have it part of its versioned item definition? The solution to have developers check which should stay on/off and mirror that introduces room for human error and inefficiencies. I struggle to understand why the active/inactive toggle cannot be handled as part of eventstream's item definition. Maybe some clarifications on that design decision could help me understand why Fabric should stay this way on this.