Forum Discussion
Advocate IIIEvent 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.
Advocate IIIHi, Ganesh. I must've missed this reply as I did not receive any notification about this.
I'm a little confused about how meta/definitions (object and its configuration) versioning would not include the configuration of whether a start/stoppable component is in its start/stop state. Would that not be part of the object's metadata? E.g. if a data pipeline may have activated/deactivated activities defined in its metadata as part of its configuration. We wouldn't expect a versioned copy of the same pipeline to have all disabled activites magically and unwantedly activated, yes?
This is an example of a simple eventstream and the "active/inactive" buttons are not considered "metadata" or "configuration" of an eventstream? That's one of the first few obvious (and very important) things that shows on the interface which I think makes no sense if it's not considered "metatdata/definition of items".
I could also see how this may impact scaling and productivity if a simple "active/inactive" option wasn't considered part of the eventstream's metadata. E.g. one workspace has 5 event streams with different sources/destinations in active/inactive state then 10 developers work on branching out this workspace to each work on their tasks, involving the eventstreams or not. They would all then have to manually sync up on which should stay on/off. Perhaps more manageable if they were working on those eventstreams but if they're working on other workspace items, I can see how this could be easily overlooked and incur unnecessary CU cost because developers didn't look where they shouldn't have to. Not to mention how this means every developer working on the workspace would have to check if it has an eventstream object within?
I don't think git integration was designed to exclude this essential piece of configuration of eventstreams but I may be wrong.
Community SupportHi scca,
Thank you for the detailed clarification and for sharing the example.
In Fabric, the Active / Inactive toggle for an Eventstream is handled as a runtime execution state, not as part of the versioned item definition. Git integration versions the artifact definition and configuration (sources, destinations, mappings, connections), while execution state (whether the Eventstream is currently running) is managed independently at the workspace level.
This differs from pipelines, where enabled/disabled activities are stored directly in the pipeline definition. For Eventstreams, the start/stop state is evaluated by the workspace runtime and capacity, which is why it is not carried over during Git sync operations.
As a result, when an Eventstream is synced into another workspace (such as a working or feature branch), it can appear in an active state and should be explicitly reviewed and stopped if not required. This applies regardless of whether the Eventstream is being actively modified or simply present in the workspace.
Best regards,
Ganesh Singamshetty.