Event Stream Disabled In Main Branch But Enabled In Sub-Branch Using Git Integration Draining CUs

[scca]

I'm trying out Git Integration here to implement better version control but just now I realised that event streams that I have disabled in the workspace that's tied to my "main" branch is enabled in the other workspace that's connected to my "working branch". Best part? I didn't even know this until someone on my team caught that CU consumption shot up out of the blue. This caught me by surprise as I'd have expected the git sync process to cover even the if something was "on or off". Does anyone know if this is expected behaviour of git integration? It makes no sense to me. Imagine if I have a feature to work on and I branched out to a new workspace, work on it for days without knowing this and it just ate my CUs dry. It's even worse if you consider multiple developers working off the same workspace (i.e. each branching out to their own). 

[v-ssriganesh]

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.

[scca]

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. 

[v-ssriganesh]

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.

[v-ssriganesh]

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.

[scca]

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. 

[v-ssriganesh]

Hi @scca,
Thank you for posting your query in the Microsoft Fabric Community Forum.

Git integration only versions the metadata/definition of items (such as the Eventstream object and its configuration). It does not synchronize the runtime state, including whether an Eventstream is started or stopped.

As a result, after syncing to a dev or feature-branch workspace, it’s important to explicitly verify and stop Eventstreams (and other runtime artifacts) to avoid unintended CU consumption. Using separate low-capacity dev workspaces and maintaining a post-sync checklist can also help prevent this.

Best regards,
Ganesh Singamshetty.

[scca]

Hi, 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. 

[v-ssriganesh]

Hi @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.