Framework-agnostic broadcast for Fly log and deploy events.

ExAtlas cannot hard-depend on Phoenix.PubSub because many consumers do not use Phoenix. This dispatcher picks one of three backends based on application config (config :ex_atlas, :fly, dispatcher: ...):

• :registry (default) — atlas starts its own Registry with duplicate keys. Subscribers register the caller pid; dispatch/2 sends the message via send(pid, message).

• :phoenix_pubsub — requires phoenix_pubsub to be present in the host app's deps and config :ex_atlas, :fly, pubsub: MyApp.PubSub. Uses Phoenix.PubSub.subscribe/2 + broadcast/3.

• {:mfa, {mod, fun, extra_args}} — on dispatch, calls apply(mod, fun, [topic, message | extra_args]). Subscription is a no-op (the host owns delivery).

Topics & messages

• Logs: topic "ex_atlas_fly_logs:#{app}", message {:ex_atlas_fly_logs, app, entries}
• Deploy: topic "ex_atlas_fly_deploy:#{ticket_id}", message {:ex_atlas_fly_deploy, ticket_id, line}

These shapes are stable — hosts match on them in handle_info/2.

Dispatch semantics (H7)

In :registry mode, dispatch/2 uses Registry.dispatch/3 which runs the fan-out send/2 loop inside the caller's process while holding the registry partition lock. send/2 itself is async (no back-pressure from the receiver), so dispatch time scales linearly with the number of subscribers. For typical log-streaming / deploy workloads this is negligible (a handful of subscribers per topic). Hosts with large fan-out should use :phoenix_pubsub mode.

Subscribers with full mailboxes are not removed automatically — use subscribe_with_backpressure/2 if you need auto-eviction of slow consumers (see E6).