Reactor Catalogue

A generic "some entity changed" signal was designed and then removed. A bulk import of 500 participants would emit 500 signals; even squashed by entity type, the table becomes noise, and the remote APIs that would consume it are better served by batched updates. Change detection for sync already exists as timestamp comparison, which is a sweep by another name. See DataSyncReactor — sweep-only.

If a future integration genuinely needs near-real-time push, add a target-specific signal type rather than resurrecting a generic one.

Handles registration and payment communications. Two decisions shape it:

Order-level, not participant-level. One email per order, addressed to the billing email. An order with seventeen participants sends one message, not seventeen to the same inbox. Order and participant emails carry genuinely different content — an order email is buyer-facing (reference, total, payment status, one pay link, a summary of who is entered), a participant email is athlete-facing (their category, race number, start group, event-day logistics). They are separate templates, not one template with a different recipient. Per-participant email is a later addition.

Direct, not via Fluxnova — for now. The framework routes single-step reactions in-process and reserves Fluxnova for multi-step orchestration. Order confirmation is single-step, and Fluxnova remains deployed but unconfigured, so the reactor calls the email service directly. Multi-step escalation — a payment reminder sequence with channel fallback — remains the Fluxnova case and will be added as a separate path rather than by rewriting this one.

Idempotency is a hard prerequisite. A reactor that sends email will be retried by the framework after a transient SMTP failure. Without a dedup guard in communication_log, that retry sends a second real email to a real customer. The guard must be in place before this reactor is enabled anywhere. See Email Service.

The bi-directional sync framework already detects change by comparing lastModifiedMain and lastModifiedRemote timestamps. That is a sweep. Adding reactive signals on top would duplicate the detection, flood the signal table during bulk imports, and turn efficient batch API calls into chatty per-entity ones.

The sweep runs every five minutes, collects everything changed since the last watermark, and submits it in one batch. See Data Synchronisation.

Closes the loop on the DETACH-and-reconcile cascade introduced by Feature #473. When an admin reassigns a race number, the system nulls number_id on the same participant’s future same-type event participants. Those sit unassigned until something reconciles them — this reactor.

It selects event participants with a null number on future events whose event type requires one, then calls the pool service per participant in its own transaction, so one failure does not block the rest. Assignment obeys ADR-0006: prefer the participant’s latest used number of that subtype, else draw from stock; if their latest is UNFIT_FOR_SERVICE, leave it unassigned and surface it as a validation error rather than auto-assigning.

Until this reactor exists, reconciliation is manual via the event-finalisation gate.

The existing LeaderboardSynchronizationService was the intended first migration: it already implements the signal-plus-poll pattern, using an in-memory map that does not survive restarts. Moving it onto the framework would give it durability, retry and visibility.

That migration is deferred. Its core operation — upserting calculated entries into a ResultSet — is still an unimplemented TODO, so the service currently computes leaderboard entries and discards them. Migrating it would validate nothing about the framework and would move a half-finished feature onto new foundations.

Until then, ResultSetChangedEvent and LeaderboardSynchronizationService stay exactly as they are. Where RESULT_SET_CHANGED signals are emitted, they are emitted alongside the existing Spring ApplicationEvent, not instead of it, so leaderboard behaviour is unchanged.