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,
Thank you for continuing the discussion.
In Fabric, the distinction comes from how item definition and execution lifecycle are separated. The Eventstream definition represents what the Eventstream is (its sources, destinations, schema, and connections), while the Active / Inactive toggle represents whether the workspace runtime is currently executing it. That execution decision is evaluated per workspace and per capacity, rather than being embedded in the item definition.
Because Git integration is scoped to versioning the definition of items, it intentionally does not apply or enforce execution lifecycle decisions across workspaces. This prevents Git operations from implicitly controlling or altering runtime behavior in another environment, were capacity, connectivity or operational intent may differ.
This is why an Eventstream that is inactive in one workspace can appear active when synced into another workspace the item definition is the same, but each workspace independently manages whether that definition is executed.
Best regards,
Ganesh Singamshetty.
Could you provide a scenario where this works nicely for people branching out from a main workspace that has evenstream items turned off but then defaults to "active" when checked out into a feature branch workspace? If it's a copy of the workspace that I want to keep and use differently then I may understand this (still have doubts though) but if it's a feature branch (temp workspace) that will be merged back to main workspace and deleted after that's done, I don't see any benefits of having users going through the process of checking and mirroring active/inactive toggles because Fabric didn't want to just do mirroring from the get-go via git sync.
While I may see how "not applying/enforcing execution lifecycle decisions" may "prevent git operations from implicitly controlling or alter runtime behaviour" works on paper, in reality it's already not working that way in my scenario, i.e. eventstream set to not run but defaults to "active" in the feature branch, and that in itself has already "altered runtime behaviour" because it assumes I want eventstreams online by default? I get how if operational intent differs then yeah, we'd make that change ourselves but in this scenario, the operational intent is the same but the system makes the changes for us because assumptions are made/set (not by the user)?
Besides that, what's the challenge of incorporating source and destinations active/inactive toggles as part of eventstream's item definition? In my head, the item definitions/metadata would be something like a json that describes them. That said, what's the challenge of having something like
{
"source":{
"name":"xxx",
"connection":"yyy",
"status":"inactive" <-- have this in eventstream item definition
}
}as part of the source/destination definition of eventstreams because from the user's POV, that is what defines the eventstream.