Event Cancellation Culprit Logging

[underscore11code]

Is your feature request related to a problem?

A not-uncommon problem with certain types of plugins, especially ones which mirror chat to other platforms i.e. Discord, is that..."special" plugins will handle events improperly, cancelling events and mimicking their behavior instead of allowing Paper to handle it. This causes problems for the consuming plugins, since as far as they're concerned, the event was cancelled and thus should be ignored.

The dumplisteners command helps tremendously with this problem, as it allows narrowing down the culprits to only those who listen to the relevant events, however this can still leave 10-20 plugins which needs to be binary searched or whatever, and I think we can streamline that a bit.

Describe the solution you'd like.

First, whatever the implementation, I'd like it to be accessible both via commands for admins to do manually, and some sort of API so plugins can attempt to automatically diagnose problems if desired.

What would be (in my opinion) the best solution would be the introduction of an EventCancelledEvent (perhaps with a different name). This would include both the original Cancellable event, as well as the RegisteredListener, or other relevant data as to the plugin who cancelled the event, and ideally the specific Listener class.

The command system would look something like /paper logcancellations <event class> -> that player would begin receiving messages for every EventCancelledEvent of , until they disconnect or disable it with something like /paper stoploggingcancellations <event class>.

I acknowledge that the event manager is a hot code path, so I suspect this implementation might need to be optimized to be viable, or perhaps locked behind a default-disabled flag or such. Some ideas include only firing the event for Event classes which clients have explicitly requested EventCancelledEvent be fired for, only firing it for a hardcoded whitelist of events (not great for custom plugin events), etc. Open for input as to other ideas.

Describe alternatives you've considered.

I imagine it's probably possible to accomplish roughly the same end result with some reflections hackery overriding the event manager, but that's...less than ideal.

Other

I'm willing to PR this myself, I'm mainly opening this to get input as to a) whether or not this is something the dev team is interested in accepting, and if so, b) what implementation I should do.

I'm on the Paper discord @_11 if you want to talk there instead

[ghost]

You can use HandlerList.getHandlerLists() to get the handler lists of all events. You can then use this to either analyze all registered event handlers for all events, or register your own event handler(s) for each event.

You could for example register a handler at each event priority in each handler list and use that to monitor at which point the events got cancelled. And you can get all the registered event handlers of all other plugins and their event priorities, and then use this combined information to figure out which plugin cancelled the event.

[Machine-Maker]

We have an open PR (#9024) that provides for more indepths logging for events. Tracking each handler and the state of each event before and after each handler is run. I think that would probably cover this.