Skip to content

Conversation

@adinauer
Copy link
Member

@adinauer adinauer commented Apr 12, 2024

#skip-changelog

📜 Description

There's a lot of open questions, we should discuss.

💡 Motivation and Context

💚 How did you test it?

📝 Checklist

  • I reviewed the submitted code.
  • I added tests to verify the changes.
  • No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
  • I updated the docs if needed.
  • Review from the native team if needed.
  • No breaking change or entry added to the changelog.
  • No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

adinauer and others added 30 commits March 27, 2024 16:30
@github-actions
Copy link
Contributor

github-actions bot commented Apr 12, 2024

Messages
📖 Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 2b05019

}
withType<JavaCompile> {
options.compilerArgs.addAll(arrayOf("-Xlint:all", "-Werror", "-Xlint:-classfile", "-Xlint:-processing"))
options.compilerArgs.addAll(arrayOf("-Xlint:all", "-Werror", "-Xlint:-classfile", "-Xlint:-processing", "-Xlint:-try"))
Copy link
Member Author

Choose a reason for hiding this comment

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

This allows us to write:

try(ISentryLifecycleToken ignored = scopes.makeCurrent()) {
	...
}

and rely on AutoClosable to clean up scopes.

Copy link
Member

Choose a reason for hiding this comment

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

👍 why do you have to disable this warning? Does it complain every time you're not using the API with a try block?

Copy link
Member Author

Choose a reason for hiding this comment

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

It complains about not using the variable (called ignored here) inside the try {} block.

@Override
@SuppressWarnings("JavaUtilDate")
public int compareTo(@NotNull Breadcrumb o) {
// TODO also use nano time if equal
Copy link
Member Author

@adinauer adinauer Apr 12, 2024

Choose a reason for hiding this comment

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

To fix breadcrumb ordering across multiple collections when combining scopes - so we can maintain insertion order as well as possible. If this isn't good enough we might need some atomic counter we increment for each breadcrumb.

Copy link
Member Author

Choose a reason for hiding this comment

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

Implemented in #3355


@Override
public void removeTag(@NotNull String key) {
// TODO should this go to all scopes?
Copy link
Member Author

Choose a reason for hiding this comment

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

Deleting certain things from scope can be tricky with new API since deletions might go to the wrong scope. Maybe we should just delete from all scopes. On the other hand a user might just want to shadow something temporarily so maybe deleting everywhere isn't wanted.

Copy link
Member Author

Choose a reason for hiding this comment

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

When calling removeX on current scope where scope has been forked since adding e.g. the tag in a parent scope, the remove only removes it from the current scope, not from the parent.

Copy link
Member

Choose a reason for hiding this comment

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

Good point, yeah that's tricky!
From a user perspective, I expect it to behave in-sync with setting a value, so I wouldn't remove the value from all scopes.
I'm wondering if we could treat remove<xy>() like a set<xy>(null) instead.

When retrieving scope values we then would need to change the behavior as well. From ~

return current.value ?: scope.value ?: global.value

To something like this ~

return if (current.isSet) {
	current.value // can still be null
} else if (scope.isSet) {
	scope.value
} else {
	global.value
}

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah I agree on not removing from all and making it behave the same way set does.

Not so sure about setting null and returning that because how do you ever unset this?

As a workaround for users actually wanting to clear certain values from all scopes, we could offer a ScopeType.ALL where we send set, remove etc. to all scopes, when they run Sentry.configureScope(ScopeType.ALL) { scope -> ... }

Copy link
Member Author

Choose a reason for hiding this comment

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

If users want to shadow something in the sense of temporarily unsetting, we'd have to use Optional for all values I guess.

GLOBAL,

// TODO do we need a combined as well so configureScope
COMBINED;
Copy link
Member Author

Choose a reason for hiding this comment

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

This would allow users to use .configureScope() and be able to access the combined view of all scopes relevant, so they can read the same way SentryClient would.

Copy link
Member

Choose a reason for hiding this comment

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

The use case would be relevant for reading data from the scope right?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, cross platform SDKs (via InternalSentrySdk) are the primary use case atm. I'm about to play around with this but I'm gonna need help testing cross platform SDKs after the change.

}

private IScope getSpecificScope(final @Nullable ScopeType scopeType) {
// TODO extract and reuse
Copy link
Member Author

Choose a reason for hiding this comment

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

move to CombinedScopeView as well?

Copy link
Member Author

Choose a reason for hiding this comment

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

Implemented in #3361

@github-actions
Copy link
Contributor

github-actions bot commented Apr 12, 2024

Performance metrics 🚀

  Plain With Sentry Diff
Startup time 398.35 ms 447.49 ms 49.14 ms
Size 1.70 MiB 2.28 MiB 595.97 KiB

Previous results on branch: feat/hsm-27-discussions

Startup times

Revision Plain With Sentry Diff
fc49fab 391.51 ms 458.73 ms 67.22 ms

App size

Revision Plain With Sentry Diff
fc49fab 1.70 MiB 2.28 MiB 595.97 KiB

}

private @NotNull IScope getDefaultWriteScope() {
// TODO use Scopes.getSpecificScope?
Copy link
Member Author

Choose a reason for hiding this comment

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

Implemented in #3361

}

private IScope getCombinedScopeView() {
// TODO create in ctor?
Copy link
Member Author

Choose a reason for hiding this comment

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

Implemented in #3361

Base automatically changed from feat/hsm-26-coroutine-wrapper to 8.x.x April 22, 2024 14:17
@adinauer
Copy link
Member Author

All discussions have been addressed in follow up PRs.

@adinauer adinauer merged commit a3ba20a into 8.x.x Apr 22, 2024
@adinauer adinauer deleted the feat/hsm-27-discussions branch April 22, 2024 14:24
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.

3 participants