Skip to content

Per-Scope event handlers #91

Open

Description

@vheathen

syn has one event handler per node. syn:set_event_handler/1 stores the module in the application environment, and every callback, resolve_registry_conflict/4 included, goes to that module. Callbacks get the Scope as an argument, so the module can branch on it, but there is only one module for the whole node.

This breaks down when two independent libraries use syn in the same VM, each with its own Scopes and its own event handler. For example, library A needs a resolve_registry_conflict/4 that compares start timestamps it keeps in Meta, while library B is fine with syn's default resolution and only implements on_process_unregistered/5. Neither library owns the release, and neither can change the other's module. Whichever calls set_event_handler/1 last wins, and the other library's callbacks are no longer called.

Conflicts make it worse. If library A's handler wins, conflicts in B's Scopes go to A's resolver. A's resolver does not understand B's Meta, and if it raises, syn logs the error and both nodes drop the name, so B loses the registration. The workaround is a handler that remembers the module installed before it and forwards the callbacks of Scopes it does not own. That only works if every library does the same, and the result still depends on the order in which they start.

#55 asked for the same thing, and a callback module per Scope was sketched there.

Proposal: syn:set_event_handler(Scope, Module). A Scope with its own module uses it for all of its callbacks. A Scope without one uses the node-wide event_handler, and syn's defaults if there is none. set_event_handler/1 and the event_handler key stay as they are. Scopes that syn starts itself from the scopes key exist before application code can call anything, so for them there is a scope_event_handlers key, a list of {Scope, Module} tuples, applied before those Scopes start.

We have exactly this situation, different Scopes in one VM that need different handlers, so we are rolling this out to production from our fork, https://github.com/Qarma-inspect/syn. The change itself, with docs and tests, is on https://github.com/vheathen/syn/tree/scope-event-handlers. I've already opened a pull request with it, #93, in case you want to take it.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions