Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

feat: Event objects #51

Open
wants to merge 25 commits into
base: main
Choose a base branch
from
Open

feat: Event objects #51

wants to merge 25 commits into from

Conversation

limbonaut
Copy link
Collaborator

@limbonaut limbonaut commented Dec 23, 2024

This PR implements:

  • SentryEvent objects, which can be used to create or modify an event, and a native implementation.
    • NativeEvent class -- implementation used with NativeSDK
  • Add SentrySDK.capture_event(event), SentrySDK.create_event(), SentrySDK.create_message_event() methods.
  • Unit tests for the SentryEvent class and SDK methods.

In future PRs, we can implement accessing tags, breadcrumbs, contexts, fingerprint, etc.

Dependency for:

@limbonaut limbonaut added the enhancement New feature or request label Dec 23, 2024
src/sentry_sdk.h Outdated
String get_last_event_id() const;

Ref<SentryEvent> create_event() const;
Ref<SentryEvent> create_message_event(const String &p_message, sentry::Level p_level = sentry::LEVEL_INFO, const String &p_logger = "");
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Do we need to expose logger? It's unclear what it's used for.

Choose a reason for hiding this comment

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

I don't see the use for logger either. Logging itself is setup during initialization, right?

Copy link
Collaborator Author

@limbonaut limbonaut Jan 10, 2025

Choose a reason for hiding this comment

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

Our error logger is set up at initialization and has nothing to do with this. I'm not even sure what this field is used for. This logger bit is a part of event payload:

Maybe we just remove this part from function call, but leave it as property of SenteryEvent?

Copy link
Collaborator Author

@limbonaut limbonaut Jan 10, 2025

Choose a reason for hiding this comment

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

It's a part of sentry-native call, so I left it as is:
https://github.com/getsentry/sentry-native/blob/3981ea7e7fd012524e4c04501c9dd647563aa391/include/sentry.h#L377-L380
We also have it in capture_message signature.

@limbonaut limbonaut marked this pull request as ready for review January 3, 2025 19:22
Copy link

github-actions bot commented Jan 8, 2025

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

Generated by 🚫 dangerJS against 8e3ac2c

Copy link

@bitsandfoxes bitsandfoxes left a comment

Choose a reason for hiding this comment

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

This looks good to me!
I'm just questioning the usecase of create_message_event.


#include "sentry_event.h"

// Event class that is used when the SDK is disabled.

Choose a reason for hiding this comment

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

Where does the need for a DisabledEvent come from? Can't we use the SentryEvent and still have the SDK disabled?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

SentryEvent is abstract and cannot be instantiated, and it's supposed to be implemented by NativeEvent class and such (for each internal SDK used). The reason behind DisabledEvent is to return a non-null value, so that it doesn't break scripts which may not be checking if SentrySDK is enabled. I could put this logic into SentryEvent, but it would add some bloated state to each event. I.e. SentryEvent is basically an interface.


namespace {

inline void _sentry_value_set_or_remove_string_by_key(sentry_value_t value, const char *k, const String &v) {

Choose a reason for hiding this comment

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

So we end up with shortcuts and instead of event.remove_release() we want users to use event.set_release("")?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Not sure if I understand the question. This is a helper method. It sets a string value on a sentry_value object, unless the string is empty, in which case it removes such key. Hence, the name of the method.
So we don't store such values:
os.name = ""
Instead, we remove the os.name key-value from the object.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Oh, I think I see what you mean. We have a pair of setter/getter for each property of SentryEvent.
event.release is how we access it in GDScript. event.release = "some_release" is how we set it. So in order to remove the value, we would be doing event.release = ""

Copy link
Collaborator Author

@limbonaut limbonaut Jan 10, 2025

Choose a reason for hiding this comment

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

@bitsandfoxes Do you think we need explicit methods for removing event properties?

Comment on lines 180 to 187
Ref<SentryEvent> NativeSDK::create_message_event(const String &p_message, sentry::Level p_level, const String &p_logger) {
sentry_value_t event_value = sentry_value_new_message_event(
native::level_to_native(p_level),
p_logger.utf8().get_data(),
p_message.utf8().get_data());
Ref<SentryEvent> event = memnew(NativeEvent(event_value));
return event;
}

Choose a reason for hiding this comment

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

I'm wondering, what's the usecase for this over capture_message?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Technically, this is not necessary, as you can add an event, set its message and level properties, and whichever other properties you need. So this can be removed - it's a shortcut for creating customized message events. I think I took it from some other SDKs, I'm not sure.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Removed in 8e3ac2c

src/sentry_sdk.h Outdated
String get_last_event_id() const;

Ref<SentryEvent> create_event() const;
Ref<SentryEvent> create_message_event(const String &p_message, sentry::Level p_level = sentry::LEVEL_INFO, const String &p_logger = "");

Choose a reason for hiding this comment

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

I don't see the use for logger either. Logging itself is setup during initialization, right?

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants