make EventProcessor.process Nullable

[davemt]

Null return is used when the event should be dropped. This aligns with the current handling in sentry-android code and also with the Sentry unified API definition of event processors.

📢 Type of change

• Bugfix
• New feature
• Enhancement
• Refactoring

📜 Description

💡 Motivation and Context

Alignment with unified API https://develop.sentry.dev/sdk/unified-api/#terminology

💚 How did you test it?

📝 Checklist

• I reviewed submitted code
• I added tests to verify changes
• All tests passing
• No breaking changes

🔮 Next steps

[bruno-garcia]

@davemt Thanks for contributing.
You're right that it should be nullable, it was just missing the annotation.

Please add it to the implementations too? Also, since this will break anyone implementing this interface (as it broke the build), please set the base branch to 3.0.0 which we're holding our new breaking changes that will land on version 3.0.0

[davemt]

The in-project implementations (e.g. MainEventProcessor, DefaultAndroidEventProcessor) happen to not be able to return null and so can technically be marked NotNull, even with the Nullable allowance specified on the interface. Would it be better to mark them as Nullable to match interface regardless?

[bruno-garcia]

Would it be better to mark them as Nullable to match interface regardless?

You're right, it's best to mark them explicitly to what they do there: @NotNull. The interface on the other hand is @Nullable.

The code in the client already behaves properly, so it's just a matter of annotation:

sentry-android/sentry-core/src/main/java/io/sentry/core/SentryClient.java

Lines 81 to 93 in e8b5549

	for (EventProcessor processor : options.getEventProcessors()) {
	event = processor.process(event, hint);
	if (event == null) {
	options
	.getLogger()
	.log(
	SentryLevel.DEBUG,
	"Event was dropped by processor: %s",
	processor.getClass().getName());
	break;
	}
	}