Skip to content

Conversation

@KnapSac
Copy link
Contributor

@KnapSac KnapSac commented Jun 2, 2025

Fixes #4228.

@KnapSac KnapSac force-pushed the feat/4228/configure-scope-non-allocating branch from 558753a to b3239bb Compare June 3, 2025 18:44
@KnapSac KnapSac marked this pull request as ready for review June 3, 2025 19:02
@KnapSac KnapSac requested a review from aritchie as a code owner June 3, 2025 19:02
@KnapSac KnapSac force-pushed the feat/4228/configure-scope-non-allocating branch from b3239bb to 1d617ae Compare June 4, 2025 17:40
Comment on lines 160 to 162
var verified = false;
var scope = new Scope();
_fixture.Hub
.When(h => h.ConfigureScope(Arg.Any<Action<Scope>>()))
.Do(Callback
.First(c => c.ArgAt<Action<Scope>>(0)(scope))
.Then(_ =>
{
Assert.True(scope.Locked);
verified = true;
}));
var scopeLocked = false;
_fixture.Hub.When(h => h.PushAndLockScope()).Do(_ => scopeLocked = true);
_fixture.Hub.When(h => h.ConfigureScope(Arg.Any<Action<Scope>>()))
.Do(_ => Assert.True(scopeLocked));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed this test slightly because I couldn't get it to work with the new overload. It seems to me like this still functionally tests the same thing as before, although I'm not even sure the test implementation was correct.

The test used to first invoke the ConfigureScope callback and then assert that the scope is locked, or am I misunderstanding that?

Copy link
Collaborator

@jamescrosswell jamescrosswell Jun 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the previous test was fine. It basically invoked the configurescope callback on the local var scope when this line executed (since the hub at this point is a substitute):

public static void LockScope(this IHub hub) => hub.ConfigureScope(c => c.Locked = true);

Then it checked to ensure that scope.Locked == true afterwards.

I don't think the new test is validating anything since the test code itself is trying to set scopeLocked to true and then checking to see if it's true aftewards... it's not actually testing any code in the SDK.

Note that hub.PushAndLockScope() is actually calling an extension method (so you can't mock this with NSubstitute). Ultimately what's being tested here is this line of code:

public static void UnlockScope(this IHub hub) => hub.ConfigureScope(static s => s.Locked = false);

Did HubSubstituteExtensions.SubstituteConfigureScope not work here? It looks like you used this successfully everywhere else...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, you're right. Those substitute methods take some getting used to ;). I'll take a look and try to get the old test working.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure why I can't remove the first substitute in this method, its Then callback doesn't seem to be called, but if I remove it the test no longer passes...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume you're referring to this one:

_fixture.Hub
.When(h => h.ConfigureScope(Arg.Any<Action<Scope>>()))
.Do(Callback
.First(c => c.ArgAt<Action<Scope>>(0).Invoke(scope))
.Then(_ =>
{
Assert.True(scope.Locked);
verified = true;
}));

That would ordinarily get called by HubExtensions.LockScope here:

public static void LockScope(this IHub hub) => hub.ConfigureScope(static s => s.Locked = true);

Since the test uses a substitute for the Hub, that behaviour has to be imitated by the substitute.

It's definitely a bit tricky to walk down all the paths mentally and then setup the appropriate substitutes.

In any event, this test looks all good now 👍🏻

@KnapSac KnapSac force-pushed the feat/4228/configure-scope-non-allocating branch from 4e23737 to 485257d Compare June 5, 2025 09:14
@codecov
Copy link

codecov bot commented Jun 5, 2025

Codecov Report

Attention: Patch coverage is 86.53846% with 7 lines in your changes missing coverage. Please review.

Project coverage is 72.86%. Comparing base (495e742) to head (dc5c853).
Report is 637 commits behind head on main.

Files with missing lines Patch % Lines
src/Sentry/Internal/Hub.cs 53.84% 6 Missing ⚠️
src/Sentry/Extensibility/HubAdapter.cs 50.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4244      +/-   ##
==========================================
- Coverage   75.73%   72.86%   -2.87%     
==========================================
  Files         357      458     +101     
  Lines       13466    16662    +3196     
  Branches     2671     3320     +649     
==========================================
+ Hits        10198    12141    +1943     
- Misses       2593     3672    +1079     
- Partials      675      849     +174     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fancy 😜

Copy link
Collaborator

@jamescrosswell jamescrosswell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally looking really good - just need to to get that one test working and I think we're good to go.

Copy link
Member

@bruno-garcia bruno-garcia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some minor suggestions but otherwise LGTM! Thanks!

@KnapSac KnapSac force-pushed the feat/4228/configure-scope-non-allocating branch from 2dcc6a3 to 2c8a794 Compare June 7, 2025 08:46
ITransactionTracer? currentTransaction = null;
hub.ConfigureScope(s => currentTransaction = s.Transaction);
return currentTransaction is { } transaction
return hub.GetTransaction() is { } transaction
Copy link
Member

@Flash0ver Flash0ver Jun 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

test: Should we have a test for StartSpan in HubExtensionsTests.cs

To be fair, these method was recently moved and made public, where we should have added a test for this, but missed it.
Now, that this method calls an internal method, I'm wondering if this is adding more "worth" of adding a test for this extension method.

@KnapSac, only if you feel like adding a test for this method.
To be fair, though, it should have been added in a preceding PR.

@KnapSac KnapSac force-pushed the feat/4228/configure-scope-non-allocating branch 2 times, most recently from b292964 to 55aa771 Compare June 10, 2025 15:20
@KnapSac KnapSac force-pushed the feat/4228/configure-scope-non-allocating branch from 55aa771 to aad5e0b Compare June 10, 2025 15:22
@jamescrosswell jamescrosswell self-requested a review June 11, 2025 08:19
Copy link
Collaborator

@jamescrosswell jamescrosswell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome work - thank you so much @KnapSac ! ❤️

@jamescrosswell jamescrosswell merged commit 6e50eaa into getsentry:main Jun 11, 2025
34 checks passed
@KnapSac KnapSac deleted the feat/4228/configure-scope-non-allocating branch June 11, 2025 08:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add overload to prevent delegate allocation for ConfigureScope

4 participants