rfc(decision): scope model RFC for Go by giortzisg · Pull Request #156 · getsentry/rfcs

giortzisg · 2026-03-19T11:19:58Z

This RFC evaluates how sentry-go should model scope state so it can align with Sentry’s three-scope model

Links

resolves GO-127
links to Scope Refactoring refinement sentry-go#1228

linear-code · 2026-03-19T12:09:44Z

sl0thentr0py

While I mostly understand the reasoning behind this RFC, and also partially agree with the arguments set forth, some considerations and comments:

Why 3 Scopes?

the whole point of the other 3 scope RFC was to make our scope more in line with otel copy-on-write context (which is the same design as go context) for POTEL (= bidirectional flow between sentry <-> otel)
if we already make our scope context like in this RFC suggests, we don't even need 3 scopes - just a global and a context-like scope suffices
the currentScope especially is really weird here because all it needs to hold is a span reference but we make it hold all the other stuff like tags and data and if we already have a copy-on-write structure we don't need the added complexity
honestly, since POTEL is now a dead project and we are already considering reverting it in JS, I'm not sure this whole 3-scope thing is even necessary. I'm definitely postpoining it and might not do it at all in Ruby, for instance.

Breaking Changes and Migration

We need a proper pathway for migration if we do this, so please add more clarification on this in the RFC.

Divergence

If we go forward with this in go, it will certainly create short term (if not permanent) divergence between go and other SDKs, something we have to be aware of and have buy-in from relevant people.

sl0thentr0py · 2026-03-19T13:03:08Z

+
+### Cons
+
+- Major change from current SDK architecture, both for us and the users.


we need concrete examples here on what migration would mean for the users and how much code they need to change

giortzisg · 2026-03-27T13:59:14Z

The three scope model mapping section is mostly there for associating how the proposal would work when compared to the old approach.

I also agree that we don't really need the three scopes model (or at least limit it to only two scopes) for it to actually work, so let me rework the format a bit to be more clear.

cleptric · 2026-03-31T14:55:19Z

As discussed offline, I'm in general happy with this approach, but we should include how a new span API interacts with the new scope model.

sl0thentr0py · 2026-05-05T09:53:55Z

+#### Hub-in-context APIs
+
+- SetHubOnContext(ctx, hub) and GetHubFromContext(ctx) stop being the primary user-facing propagation mechanism.
+- Users should no longer manually clone hubs for request/task isolation, just pass the correct context.Context.


this assumes that that go context forking semantics for concurrency/isolation are the same as what we were doing before. Does this hold for all cases where we manually forked before?

That's a nice observation. I would say yes, since each scope.fork snapshot is essentially a different context. For forks that prevented mutability CoW guarantees that and for forks that are a snapshot of scope state, the mechanism now would be the ctx.
The only thing I can think of is CurrentHub.Clone() which becomes completely redundant under our model, since ctx and global scope would merge anyways on send.

sl0thentr0py · 2026-05-05T10:02:24Z

+#### Interaction with scope model
+
+Under the proposed scope model, scope if only an infromation carrier and is no longer responsible for owning tracing state. The `context.Context` carries both the scope and active span state.
+This means that `StartSpan` is also a scope-boundary operation and derived scopes already contain the previously inherited local state. Under this, the SDK does not need to merge separate scopes when a span ends. Semanticaly, the model gets simplified to:


giortzisg · 2026-03-19T11:19:58Z

This RFC evaluates how sentry-go should model scope state so it can align with Sentry’s three-scope model

Rendered RFC

Links

resolves GO-127
links to Scope Refactoring refinement sentry-go#1228

linear-code · 2026-03-19T12:09:44Z

GO-127 Scope Refactoring refinement

sl0thentr0py

While I mostly understand the reasoning behind this RFC, and also partially agree with the arguments set forth, some considerations and comments:

Why 3 Scopes?

the whole point of the other 3 scope RFC was to make our scope more in line with otel copy-on-write context (which is the same design as go context) for POTEL (= bidirectional flow between sentry <-> otel)
if we already make our scope context like in this RFC suggests, we don't even need 3 scopes - just a global and a context-like scope suffices
the currentScope especially is really weird here because all it needs to hold is a span reference but we make it hold all the other stuff like tags and data and if we already have a copy-on-write structure we don't need the added complexity
honestly, since POTEL is now a dead project and we are already considering reverting it in JS, I'm not sure this whole 3-scope thing is even necessary. I'm definitely postpoining it and might not do it at all in Ruby, for instance.

Breaking Changes and Migration

We need a proper pathway for migration if we do this, so please add more clarification on this in the RFC.

Divergence

If we go forward with this in go, it will certainly create short term (if not permanent) divergence between go and other SDKs, something we have to be aware of and have buy-in from relevant people.

sl0thentr0py · 2026-03-19T13:03:08Z

+
+### Cons
+
+- Major change from current SDK architecture, both for us and the users.


we need concrete examples here on what migration would mean for the users and how much code they need to change

giortzisg · 2026-03-27T13:59:14Z

The three scope model mapping section is mostly there for associating how the proposal would work when compared to the old approach.

I also agree that we don't really need the three scopes model (or at least limit it to only two scopes) for it to actually work, so let me rework the format a bit to be more clear.

cleptric · 2026-03-31T14:55:19Z

As discussed offline, I'm in general happy with this approach, but we should include how a new span API interacts with the new scope model.

sl0thentr0py · 2026-05-05T09:53:55Z

+#### Hub-in-context APIs
+
+- SetHubOnContext(ctx, hub) and GetHubFromContext(ctx) stop being the primary user-facing propagation mechanism.
+- Users should no longer manually clone hubs for request/task isolation, just pass the correct context.Context.


this assumes that that go context forking semantics for concurrency/isolation are the same as what we were doing before. Does this hold for all cases where we manually forked before?

That's a nice observation. I would say yes, since each scope.fork snapshot is essentially a different context. For forks that prevented mutability CoW guarantees that and for forks that are a snapshot of scope state, the mechanism now would be the ctx.
The only thing I can think of is CurrentHub.Clone() which becomes completely redundant under our model, since ctx and global scope would merge anyways on send.

sl0thentr0py · 2026-05-05T10:02:24Z

+#### Interaction with scope model
+
+Under the proposed scope model, scope if only an infromation carrier and is no longer responsible for owning tracing state. The `context.Context` carries both the scope and active span state.
+This means that `StartSpan` is also a scope-boundary operation and derived scopes already contain the previously inherited local state. Under this, the SDK does not need to merge separate scopes when a span ends. Semanticaly, the model gets simplified to:


giortzisg · 2026-03-19T11:19:58Z

This RFC evaluates how sentry-go should model scope state so it can align with Sentry’s three-scope model

Rendered RFC

Links

resolves GO-127
links to Scope Refactoring refinement sentry-go#1228

linear-code · 2026-03-19T12:09:44Z

GO-127 Scope Refactoring refinement

sl0thentr0py

While I mostly understand the reasoning behind this RFC, and also partially agree with the arguments set forth, some considerations and comments:

Why 3 Scopes?

the whole point of the other 3 scope RFC was to make our scope more in line with otel copy-on-write context (which is the same design as go context) for POTEL (= bidirectional flow between sentry <-> otel)
if we already make our scope context like in this RFC suggests, we don't even need 3 scopes - just a global and a context-like scope suffices
the currentScope especially is really weird here because all it needs to hold is a span reference but we make it hold all the other stuff like tags and data and if we already have a copy-on-write structure we don't need the added complexity
honestly, since POTEL is now a dead project and we are already considering reverting it in JS, I'm not sure this whole 3-scope thing is even necessary. I'm definitely postpoining it and might not do it at all in Ruby, for instance.

Breaking Changes and Migration

We need a proper pathway for migration if we do this, so please add more clarification on this in the RFC.

Divergence

If we go forward with this in go, it will certainly create short term (if not permanent) divergence between go and other SDKs, something we have to be aware of and have buy-in from relevant people.

sl0thentr0py · 2026-03-19T13:03:08Z

+
+### Cons
+
+- Major change from current SDK architecture, both for us and the users.


we need concrete examples here on what migration would mean for the users and how much code they need to change

giortzisg · 2026-03-27T13:59:14Z

The three scope model mapping section is mostly there for associating how the proposal would work when compared to the old approach.

I also agree that we don't really need the three scopes model (or at least limit it to only two scopes) for it to actually work, so let me rework the format a bit to be more clear.

cleptric · 2026-03-31T14:55:19Z

As discussed offline, I'm in general happy with this approach, but we should include how a new span API interacts with the new scope model.

sl0thentr0py · 2026-05-05T09:53:55Z

+#### Hub-in-context APIs
+
+- SetHubOnContext(ctx, hub) and GetHubFromContext(ctx) stop being the primary user-facing propagation mechanism.
+- Users should no longer manually clone hubs for request/task isolation, just pass the correct context.Context.


this assumes that that go context forking semantics for concurrency/isolation are the same as what we were doing before. Does this hold for all cases where we manually forked before?

That's a nice observation. I would say yes, since each scope.fork snapshot is essentially a different context. For forks that prevented mutability CoW guarantees that and for forks that are a snapshot of scope state, the mechanism now would be the ctx.
The only thing I can think of is CurrentHub.Clone() which becomes completely redundant under our model, since ctx and global scope would merge anyways on send.

sl0thentr0py · 2026-05-05T10:02:24Z

+#### Interaction with scope model
+
+Under the proposed scope model, scope if only an infromation carrier and is no longer responsible for owning tracing state. The `context.Context` carries both the scope and active span state.
+This means that `StartSpan` is also a scope-boundary operation and derived scopes already contain the previously inherited local state. Under this, the SDK does not need to merge separate scopes when a span ends. Semanticaly, the model gets simplified to:


giortzisg · 2026-03-19T11:19:58Z

This RFC evaluates how sentry-go should model scope state so it can align with Sentry’s three-scope model

Rendered RFC

Links

resolves GO-127
links to Scope Refactoring refinement sentry-go#1228

linear-code · 2026-03-19T12:09:44Z

GO-127 Scope Refactoring refinement

sl0thentr0py

While I mostly understand the reasoning behind this RFC, and also partially agree with the arguments set forth, some considerations and comments:

Why 3 Scopes?

the whole point of the other 3 scope RFC was to make our scope more in line with otel copy-on-write context (which is the same design as go context) for POTEL (= bidirectional flow between sentry <-> otel)
if we already make our scope context like in this RFC suggests, we don't even need 3 scopes - just a global and a context-like scope suffices
the currentScope especially is really weird here because all it needs to hold is a span reference but we make it hold all the other stuff like tags and data and if we already have a copy-on-write structure we don't need the added complexity
honestly, since POTEL is now a dead project and we are already considering reverting it in JS, I'm not sure this whole 3-scope thing is even necessary. I'm definitely postpoining it and might not do it at all in Ruby, for instance.

Breaking Changes and Migration

We need a proper pathway for migration if we do this, so please add more clarification on this in the RFC.

Divergence

If we go forward with this in go, it will certainly create short term (if not permanent) divergence between go and other SDKs, something we have to be aware of and have buy-in from relevant people.

sl0thentr0py · 2026-03-19T13:03:08Z

+
+### Cons
+
+- Major change from current SDK architecture, both for us and the users.


we need concrete examples here on what migration would mean for the users and how much code they need to change

giortzisg · 2026-03-27T13:59:14Z

The three scope model mapping section is mostly there for associating how the proposal would work when compared to the old approach.

I also agree that we don't really need the three scopes model (or at least limit it to only two scopes) for it to actually work, so let me rework the format a bit to be more clear.

cleptric · 2026-03-31T14:55:19Z

As discussed offline, I'm in general happy with this approach, but we should include how a new span API interacts with the new scope model.

sl0thentr0py · 2026-05-05T09:53:55Z

+#### Hub-in-context APIs
+
+- SetHubOnContext(ctx, hub) and GetHubFromContext(ctx) stop being the primary user-facing propagation mechanism.
+- Users should no longer manually clone hubs for request/task isolation, just pass the correct context.Context.


this assumes that that go context forking semantics for concurrency/isolation are the same as what we were doing before. Does this hold for all cases where we manually forked before?

That's a nice observation. I would say yes, since each scope.fork snapshot is essentially a different context. For forks that prevented mutability CoW guarantees that and for forks that are a snapshot of scope state, the mechanism now would be the ctx.
The only thing I can think of is CurrentHub.Clone() which becomes completely redundant under our model, since ctx and global scope would merge anyways on send.

sl0thentr0py · 2026-05-05T10:02:24Z

+#### Interaction with scope model
+
+Under the proposed scope model, scope if only an infromation carrier and is no longer responsible for owning tracing state. The `context.Context` carries both the scope and active span state.
+This means that `StartSpan` is also a scope-boundary operation and derived scopes already contain the previously inherited local state. Under this, the SDK does not need to merge separate scopes when a span ends. Semanticaly, the model gets simplified to:


giortzisg · 2026-03-19T11:19:58Z

This RFC evaluates how sentry-go should model scope state so it can align with Sentry’s three-scope model

Rendered RFC

Links

resolves GO-127
links to Scope Refactoring refinement sentry-go#1228

linear-code · 2026-03-19T12:09:44Z

GO-127 Scope Refactoring refinement

sl0thentr0py

While I mostly understand the reasoning behind this RFC, and also partially agree with the arguments set forth, some considerations and comments:

Why 3 Scopes?

the whole point of the other 3 scope RFC was to make our scope more in line with otel copy-on-write context (which is the same design as go context) for POTEL (= bidirectional flow between sentry <-> otel)
if we already make our scope context like in this RFC suggests, we don't even need 3 scopes - just a global and a context-like scope suffices
the currentScope especially is really weird here because all it needs to hold is a span reference but we make it hold all the other stuff like tags and data and if we already have a copy-on-write structure we don't need the added complexity
honestly, since POTEL is now a dead project and we are already considering reverting it in JS, I'm not sure this whole 3-scope thing is even necessary. I'm definitely postpoining it and might not do it at all in Ruby, for instance.

Breaking Changes and Migration

We need a proper pathway for migration if we do this, so please add more clarification on this in the RFC.

Divergence

If we go forward with this in go, it will certainly create short term (if not permanent) divergence between go and other SDKs, something we have to be aware of and have buy-in from relevant people.

sl0thentr0py · 2026-03-19T13:03:08Z

+
+### Cons
+
+- Major change from current SDK architecture, both for us and the users.


we need concrete examples here on what migration would mean for the users and how much code they need to change

giortzisg · 2026-03-27T13:59:14Z

The three scope model mapping section is mostly there for associating how the proposal would work when compared to the old approach.

I also agree that we don't really need the three scopes model (or at least limit it to only two scopes) for it to actually work, so let me rework the format a bit to be more clear.

cleptric · 2026-03-31T14:55:19Z

As discussed offline, I'm in general happy with this approach, but we should include how a new span API interacts with the new scope model.

sl0thentr0py · 2026-05-05T09:53:55Z

+#### Hub-in-context APIs
+
+- SetHubOnContext(ctx, hub) and GetHubFromContext(ctx) stop being the primary user-facing propagation mechanism.
+- Users should no longer manually clone hubs for request/task isolation, just pass the correct context.Context.


this assumes that that go context forking semantics for concurrency/isolation are the same as what we were doing before. Does this hold for all cases where we manually forked before?

That's a nice observation. I would say yes, since each scope.fork snapshot is essentially a different context. For forks that prevented mutability CoW guarantees that and for forks that are a snapshot of scope state, the mechanism now would be the ctx.
The only thing I can think of is CurrentHub.Clone() which becomes completely redundant under our model, since ctx and global scope would merge anyways on send.

sl0thentr0py · 2026-05-05T10:02:24Z

+#### Interaction with scope model
+
+Under the proposed scope model, scope if only an infromation carrier and is no longer responsible for owning tracing state. The `context.Context` carries both the scope and active span state.
+This means that `StartSpan` is also a scope-boundary operation and derived scopes already contain the previously inherited local state. Under this, the SDK does not need to merge separate scopes when a span ends. Semanticaly, the model gets simplified to:


giortzisg · 2026-03-19T11:19:58Z

This RFC evaluates how sentry-go should model scope state so it can align with Sentry’s three-scope model

Rendered RFC

Links

resolves GO-127
links to Scope Refactoring refinement sentry-go#1228

linear-code · 2026-03-19T12:09:44Z

GO-127 Scope Refactoring refinement

sl0thentr0py

While I mostly understand the reasoning behind this RFC, and also partially agree with the arguments set forth, some considerations and comments:

Why 3 Scopes?

the whole point of the other 3 scope RFC was to make our scope more in line with otel copy-on-write context (which is the same design as go context) for POTEL (= bidirectional flow between sentry <-> otel)
if we already make our scope context like in this RFC suggests, we don't even need 3 scopes - just a global and a context-like scope suffices
the currentScope especially is really weird here because all it needs to hold is a span reference but we make it hold all the other stuff like tags and data and if we already have a copy-on-write structure we don't need the added complexity
honestly, since POTEL is now a dead project and we are already considering reverting it in JS, I'm not sure this whole 3-scope thing is even necessary. I'm definitely postpoining it and might not do it at all in Ruby, for instance.

Breaking Changes and Migration

We need a proper pathway for migration if we do this, so please add more clarification on this in the RFC.

Divergence

If we go forward with this in go, it will certainly create short term (if not permanent) divergence between go and other SDKs, something we have to be aware of and have buy-in from relevant people.

sl0thentr0py · 2026-03-19T13:03:08Z

+
+### Cons
+
+- Major change from current SDK architecture, both for us and the users.


we need concrete examples here on what migration would mean for the users and how much code they need to change

giortzisg · 2026-03-27T13:59:14Z

The three scope model mapping section is mostly there for associating how the proposal would work when compared to the old approach.

I also agree that we don't really need the three scopes model (or at least limit it to only two scopes) for it to actually work, so let me rework the format a bit to be more clear.

cleptric · 2026-03-31T14:55:19Z

As discussed offline, I'm in general happy with this approach, but we should include how a new span API interacts with the new scope model.

sl0thentr0py · 2026-05-05T09:53:55Z

+#### Hub-in-context APIs
+
+- SetHubOnContext(ctx, hub) and GetHubFromContext(ctx) stop being the primary user-facing propagation mechanism.
+- Users should no longer manually clone hubs for request/task isolation, just pass the correct context.Context.


this assumes that that go context forking semantics for concurrency/isolation are the same as what we were doing before. Does this hold for all cases where we manually forked before?

That's a nice observation. I would say yes, since each scope.fork snapshot is essentially a different context. For forks that prevented mutability CoW guarantees that and for forks that are a snapshot of scope state, the mechanism now would be the ctx.
The only thing I can think of is CurrentHub.Clone() which becomes completely redundant under our model, since ctx and global scope would merge anyways on send.

sl0thentr0py · 2026-05-05T10:02:24Z

+#### Interaction with scope model
+
+Under the proposed scope model, scope if only an infromation carrier and is no longer responsible for owning tracing state. The `context.Context` carries both the scope and active span state.
+This means that `StartSpan` is also a scope-boundary operation and derived scopes already contain the previously inherited local state. Under this, the SDK does not need to merge separate scopes when a span ends. Semanticaly, the model gets simplified to:


giortzisg · 2026-03-19T11:19:58Z

This RFC evaluates how sentry-go should model scope state so it can align with Sentry’s three-scope model

Rendered RFC

Links

resolves GO-127
links to Scope Refactoring refinement sentry-go#1228

linear-code · 2026-03-19T12:09:44Z

GO-127 Scope Refactoring refinement

sl0thentr0py

While I mostly understand the reasoning behind this RFC, and also partially agree with the arguments set forth, some considerations and comments:

Why 3 Scopes?

the whole point of the other 3 scope RFC was to make our scope more in line with otel copy-on-write context (which is the same design as go context) for POTEL (= bidirectional flow between sentry <-> otel)
if we already make our scope context like in this RFC suggests, we don't even need 3 scopes - just a global and a context-like scope suffices
the currentScope especially is really weird here because all it needs to hold is a span reference but we make it hold all the other stuff like tags and data and if we already have a copy-on-write structure we don't need the added complexity
honestly, since POTEL is now a dead project and we are already considering reverting it in JS, I'm not sure this whole 3-scope thing is even necessary. I'm definitely postpoining it and might not do it at all in Ruby, for instance.

Breaking Changes and Migration

We need a proper pathway for migration if we do this, so please add more clarification on this in the RFC.

Divergence

If we go forward with this in go, it will certainly create short term (if not permanent) divergence between go and other SDKs, something we have to be aware of and have buy-in from relevant people.

sl0thentr0py · 2026-03-19T13:03:08Z

+
+### Cons
+
+- Major change from current SDK architecture, both for us and the users.


we need concrete examples here on what migration would mean for the users and how much code they need to change

giortzisg · 2026-03-27T13:59:14Z

The three scope model mapping section is mostly there for associating how the proposal would work when compared to the old approach.

I also agree that we don't really need the three scopes model (or at least limit it to only two scopes) for it to actually work, so let me rework the format a bit to be more clear.

cleptric · 2026-03-31T14:55:19Z

As discussed offline, I'm in general happy with this approach, but we should include how a new span API interacts with the new scope model.

sl0thentr0py · 2026-05-05T09:53:55Z

+#### Hub-in-context APIs
+
+- SetHubOnContext(ctx, hub) and GetHubFromContext(ctx) stop being the primary user-facing propagation mechanism.
+- Users should no longer manually clone hubs for request/task isolation, just pass the correct context.Context.


this assumes that that go context forking semantics for concurrency/isolation are the same as what we were doing before. Does this hold for all cases where we manually forked before?

That's a nice observation. I would say yes, since each scope.fork snapshot is essentially a different context. For forks that prevented mutability CoW guarantees that and for forks that are a snapshot of scope state, the mechanism now would be the ctx.
The only thing I can think of is CurrentHub.Clone() which becomes completely redundant under our model, since ctx and global scope would merge anyways on send.

sl0thentr0py · 2026-05-05T10:02:24Z

+#### Interaction with scope model
+
+Under the proposed scope model, scope if only an infromation carrier and is no longer responsible for owning tracing state. The `context.Context` carries both the scope and active span state.
+This means that `StartSpan` is also a scope-boundary operation and derived scopes already contain the previously inherited local state. Under this, the SDK does not need to merge separate scopes when a span ends. Semanticaly, the model gets simplified to:


giortzisg · 2026-03-19T11:19:58Z

This RFC evaluates how sentry-go should model scope state so it can align with Sentry’s three-scope model

Rendered RFC

Links

resolves GO-127
links to Scope Refactoring refinement sentry-go#1228

linear-code · 2026-03-19T12:09:44Z

GO-127 Scope Refactoring refinement

sl0thentr0py

While I mostly understand the reasoning behind this RFC, and also partially agree with the arguments set forth, some considerations and comments:

Why 3 Scopes?

the whole point of the other 3 scope RFC was to make our scope more in line with otel copy-on-write context (which is the same design as go context) for POTEL (= bidirectional flow between sentry <-> otel)
if we already make our scope context like in this RFC suggests, we don't even need 3 scopes - just a global and a context-like scope suffices
the currentScope especially is really weird here because all it needs to hold is a span reference but we make it hold all the other stuff like tags and data and if we already have a copy-on-write structure we don't need the added complexity
honestly, since POTEL is now a dead project and we are already considering reverting it in JS, I'm not sure this whole 3-scope thing is even necessary. I'm definitely postpoining it and might not do it at all in Ruby, for instance.

Breaking Changes and Migration

We need a proper pathway for migration if we do this, so please add more clarification on this in the RFC.

Divergence

If we go forward with this in go, it will certainly create short term (if not permanent) divergence between go and other SDKs, something we have to be aware of and have buy-in from relevant people.

sl0thentr0py · 2026-03-19T13:03:08Z

+
+### Cons
+
+- Major change from current SDK architecture, both for us and the users.


we need concrete examples here on what migration would mean for the users and how much code they need to change

giortzisg · 2026-03-27T13:59:14Z

The three scope model mapping section is mostly there for associating how the proposal would work when compared to the old approach.

I also agree that we don't really need the three scopes model (or at least limit it to only two scopes) for it to actually work, so let me rework the format a bit to be more clear.

cleptric · 2026-03-31T14:55:19Z

As discussed offline, I'm in general happy with this approach, but we should include how a new span API interacts with the new scope model.

sl0thentr0py · 2026-05-05T09:53:55Z

+#### Hub-in-context APIs
+
+- SetHubOnContext(ctx, hub) and GetHubFromContext(ctx) stop being the primary user-facing propagation mechanism.
+- Users should no longer manually clone hubs for request/task isolation, just pass the correct context.Context.


this assumes that that go context forking semantics for concurrency/isolation are the same as what we were doing before. Does this hold for all cases where we manually forked before?

That's a nice observation. I would say yes, since each scope.fork snapshot is essentially a different context. For forks that prevented mutability CoW guarantees that and for forks that are a snapshot of scope state, the mechanism now would be the ctx.
The only thing I can think of is CurrentHub.Clone() which becomes completely redundant under our model, since ctx and global scope would merge anyways on send.

sl0thentr0py · 2026-05-05T10:02:24Z

+#### Interaction with scope model
+
+Under the proposed scope model, scope if only an infromation carrier and is no longer responsible for owning tracing state. The `context.Context` carries both the scope and active span state.
+This means that `StartSpan` is also a scope-boundary operation and derived scopes already contain the previously inherited local state. Under this, the SDK does not need to merge separate scopes when a span ends. Semanticaly, the model gets simplified to:


rfc(decision): scope model RFC for Go
2f73adf

giortzisg force-pushed the rfc/scope-model-for-go branch from 472b0ae to 2f73adfCompare March 19, 2026 11:24

giortzisg self-assigned this Mar 19, 2026

giortzisg marked this pull request as ready for review March 19, 2026 11:25

giortzisg requested review from cleptric, dingsdax, lcian and sl0thentr0py March 19, 2026 11:30

sl0thentr0py requested changes Mar 19, 2026
View reviewed changes

add migration path for users
f267f9d

add span api segment
32641a8

giortzisg requested review from cleptric and sl0thentr0py and removed request for cleptric April 7, 2026 10:25

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

add mutable span explanation for span api
a08ff25

sl0thentr0py approved these changes May 5, 2026
View reviewed changes

dingsdax approved these changes May 11, 2026
View reviewed changes

giortzisg added 3 commits May 21, 2026 14:01

add span api with examples
e540c79

scope updates and precedence explanation
38c43e8

Merge remote-tracking branch 'origin/main' into rfc/scope-model-for-go
d238b9d

rfc(decision): scope model RFC for Go
2f73adf

giortzisg force-pushed the rfc/scope-model-for-go branch from 472b0ae to 2f73adfCompare March 19, 2026 11:24

giortzisg self-assigned this Mar 19, 2026

giortzisg marked this pull request as ready for review March 19, 2026 11:25

giortzisg requested review from cleptric, dingsdax, lcian and sl0thentr0py March 19, 2026 11:30

sl0thentr0py requested changes Mar 19, 2026
View reviewed changes

add migration path for users
f267f9d

add span api segment
32641a8

giortzisg requested review from cleptric and sl0thentr0py and removed request for cleptric April 7, 2026 10:25

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

add mutable span explanation for span api
a08ff25

sl0thentr0py approved these changes May 5, 2026
View reviewed changes

dingsdax approved these changes May 11, 2026
View reviewed changes

giortzisg added 3 commits May 21, 2026 14:01

add span api with examples
e540c79

scope updates and precedence explanation
38c43e8

Merge remote-tracking branch 'origin/main' into rfc/scope-model-for-go
d238b9d

rfc(decision): scope model RFC for Go
2f73adf

giortzisg force-pushed the rfc/scope-model-for-go branch from 472b0ae to 2f73adfCompare March 19, 2026 11:24

giortzisg self-assigned this Mar 19, 2026

giortzisg marked this pull request as ready for review March 19, 2026 11:25

giortzisg requested review from cleptric, dingsdax, lcian and sl0thentr0py March 19, 2026 11:30

sl0thentr0py requested changes Mar 19, 2026
View reviewed changes

add migration path for users
f267f9d

add span api segment
32641a8

giortzisg requested review from cleptric and sl0thentr0py and removed request for cleptric April 7, 2026 10:25

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

add mutable span explanation for span api
a08ff25

sl0thentr0py approved these changes May 5, 2026
View reviewed changes

dingsdax approved these changes May 11, 2026
View reviewed changes

giortzisg added 3 commits May 21, 2026 14:01

add span api with examples
e540c79

scope updates and precedence explanation
38c43e8

Merge remote-tracking branch 'origin/main' into rfc/scope-model-for-go
d238b9d

rfc(decision): scope model RFC for Go
2f73adf

giortzisg force-pushed the rfc/scope-model-for-go branch from 472b0ae to 2f73adfCompare March 19, 2026 11:24

giortzisg self-assigned this Mar 19, 2026

giortzisg marked this pull request as ready for review March 19, 2026 11:25

giortzisg requested review from cleptric, dingsdax, lcian and sl0thentr0py March 19, 2026 11:30

sl0thentr0py requested changes Mar 19, 2026
View reviewed changes

add migration path for users
f267f9d

add span api segment
32641a8

giortzisg requested review from cleptric and sl0thentr0py and removed request for cleptric April 7, 2026 10:25

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

add mutable span explanation for span api
a08ff25

sl0thentr0py approved these changes May 5, 2026
View reviewed changes

dingsdax approved these changes May 11, 2026
View reviewed changes

giortzisg added 3 commits May 21, 2026 14:01

add span api with examples
e540c79

scope updates and precedence explanation
38c43e8

Merge remote-tracking branch 'origin/main' into rfc/scope-model-for-go
d238b9d

rfc(decision): scope model RFC for Go
2f73adf

giortzisg force-pushed the rfc/scope-model-for-go branch from 472b0ae to 2f73adfCompare March 19, 2026 11:24

giortzisg self-assigned this Mar 19, 2026

giortzisg marked this pull request as ready for review March 19, 2026 11:25

giortzisg requested review from cleptric, dingsdax, lcian and sl0thentr0py March 19, 2026 11:30

sl0thentr0py requested changes Mar 19, 2026
View reviewed changes

add migration path for users
f267f9d

add span api segment
32641a8

giortzisg requested review from cleptric and sl0thentr0py and removed request for cleptric April 7, 2026 10:25

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

add mutable span explanation for span api
a08ff25

sl0thentr0py approved these changes May 5, 2026
View reviewed changes

dingsdax approved these changes May 11, 2026
View reviewed changes

giortzisg added 3 commits May 21, 2026 14:01

add span api with examples
e540c79

scope updates and precedence explanation
38c43e8

Merge remote-tracking branch 'origin/main' into rfc/scope-model-for-go
d238b9d

rfc(decision): scope model RFC for Go
2f73adf

giortzisg force-pushed the rfc/scope-model-for-go branch from 472b0ae to 2f73adfCompare March 19, 2026 11:24

giortzisg self-assigned this Mar 19, 2026

giortzisg marked this pull request as ready for review March 19, 2026 11:25

giortzisg requested review from cleptric, dingsdax, lcian and sl0thentr0py March 19, 2026 11:30

sl0thentr0py requested changes Mar 19, 2026
View reviewed changes

add migration path for users
f267f9d

add span api segment
32641a8

giortzisg requested review from cleptric and sl0thentr0py and removed request for cleptric April 7, 2026 10:25

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

add mutable span explanation for span api
a08ff25

sl0thentr0py approved these changes May 5, 2026
View reviewed changes

dingsdax approved these changes May 11, 2026
View reviewed changes

giortzisg added 3 commits May 21, 2026 14:01

add span api with examples
e540c79

scope updates and precedence explanation
38c43e8

Merge remote-tracking branch 'origin/main' into rfc/scope-model-for-go
d238b9d

rfc(decision): scope model RFC for Go
2f73adf

giortzisg force-pushed the rfc/scope-model-for-go branch from 472b0ae to 2f73adfCompare March 19, 2026 11:24

giortzisg self-assigned this Mar 19, 2026

giortzisg marked this pull request as ready for review March 19, 2026 11:25

giortzisg requested review from cleptric, dingsdax, lcian and sl0thentr0py March 19, 2026 11:30

sl0thentr0py requested changes Mar 19, 2026
View reviewed changes

add migration path for users
f267f9d

add span api segment
32641a8

giortzisg requested review from cleptric and sl0thentr0py and removed request for cleptric April 7, 2026 10:25

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

add mutable span explanation for span api
a08ff25

sl0thentr0py approved these changes May 5, 2026
View reviewed changes

dingsdax approved these changes May 11, 2026
View reviewed changes

giortzisg added 3 commits May 21, 2026 14:01

add span api with examples
e540c79

scope updates and precedence explanation
38c43e8

Merge remote-tracking branch 'origin/main' into rfc/scope-model-for-go
d238b9d

rfc(decision): scope model RFC for Go
2f73adf

giortzisg force-pushed the rfc/scope-model-for-go branch from 472b0ae to 2f73adfCompare March 19, 2026 11:24

giortzisg self-assigned this Mar 19, 2026

giortzisg marked this pull request as ready for review March 19, 2026 11:25

giortzisg requested review from cleptric, dingsdax, lcian and sl0thentr0py March 19, 2026 11:30

sl0thentr0py requested changes Mar 19, 2026
View reviewed changes

add migration path for users
f267f9d

add span api segment
32641a8

giortzisg requested review from cleptric and sl0thentr0py and removed request for cleptric April 7, 2026 10:25

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

lcian reviewed Apr 8, 2026
View reviewed changes

Comment threadtext/0156-scope-model-for-go.md

add mutable span explanation for span api
a08ff25

sl0thentr0py approved these changes May 5, 2026
View reviewed changes

dingsdax approved these changes May 11, 2026
View reviewed changes

giortzisg added 3 commits May 21, 2026 14:01

add span api with examples
e540c79

scope updates and precedence explanation
38c43e8

Merge remote-tracking branch 'origin/main' into rfc/scope-model-for-go
d238b9d


		### Cons

		- Major change from current SDK architecture, both for us and the users.

Uh oh!

Uh oh!

Conversation

giortzisg commented Mar 19, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Links

Uh oh!

linear-codeBot commented Mar 19, 2026

Uh oh!

sl0thentr0py left a comment

Choose a reason for hiding this comment

Why 3 Scopes?

Breaking Changes and Migration

Divergence

Uh oh!

Choose a reason for hiding this comment

Uh oh!

giortzisg commented Mar 27, 2026

Uh oh!

cleptric commented Mar 31, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

giortzisg commented Mar 19, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Links

Uh oh!

linear-codeBot commented Mar 19, 2026

Uh oh!

sl0thentr0py left a comment

Choose a reason for hiding this comment

Why 3 Scopes?

Breaking Changes and Migration

Divergence

Uh oh!

Choose a reason for hiding this comment

Uh oh!

giortzisg commented Mar 27, 2026

Uh oh!

cleptric commented Mar 31, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

giortzisg commented Mar 19, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

giortzisg commented Mar 19, 2026•
edited
Loading

giortzisg commented Mar 19, 2026•
edited
Loading

giortzisg commented Mar 19, 2026•
edited
Loading

giortzisg commented Mar 19, 2026•
edited
Loading