Signal Emitter Map

A reactor is only as trustworthy as the emitter behind it. If one write path raises a signal and a sibling path does not, the reactor appears to work — it fires when tested and stays silent in production, and the silence looks identical to "nothing happened".

That failure has already occurred once. RESULT_SET_CHANGED was delivered as part of the emitter story and is emitted only from a deprecated import path; the canonical bulk import and the entire REST surface for results are silent. It was found by tracing before an exercise, not by a test.

This page exists so that the question "which paths raise this signal, and which paths should but do not?" has a written answer that can be checked, rather than being re-derived by whoever next needs to know.

Reactor Catalogue documents what consumes signals. This page documents what produces them.

Signal coverage is work in progress, and this page is a map of where it has reached — not a defect register.

The Signal & Sweep work is being delivered in phases against the design journal, its ADO stories and these pages. The framework was released early, and knowingly, so that the machinery could be exercised against a real environment rather than only against tests. Nobody expects the signal catalogue to be complete.

Two different things are therefore being tracked here, and they carry different expectations:

So an entry below marked silent is usually not yet built rather than broken. The value of writing them down is that the distinction stops being implicit: a path nobody has wired yet and a path that was supposed to be wired and is not look identical from the outside, and only one of them is a problem.

Where a gap does look like a genuine defect rather than unbuilt scope, it is called out as such in Which gaps are unbuilt, and which look wrong.

Static call-graph tracing against admin-service develop at ecfa626f. For each signal type: locate every SignalPublisher.emit call site, identify the enclosing method, and trace callers outward to a REST endpoint or scheduled entry point. Then, for the same domain state, enumerate sibling write paths and check each for an emit.

Two limits worth stating:

Where a path is marked silent, that means no emit was found on it. It does not by itself mean the path should emit — that is a product decision, and the gap register separates the two.

SignalTypes declares three constants. application.yml configures debounce windows for eight names.

Five of the eight configured types do not exist in code. They are not declared in SignalTypes and appear nowhere outside the configuration file. Reading application.yml alone gives the impression of an eight-signal framework; three are real.

These five are planned, not missing. The configuration was written from the intended catalogue, ahead of the emitters, and two of them already have an obvious owning service waiting: PersonMergeService writes participants and would raise PERSON_MERGED; CategoryChangeServiceEx changes categories and would raise PARTICIPANT_CATEGORY_CHANGED.

Nothing breaks at runtime — a debounce entry for a type never emitted is never consulted. The only real cost is legibility: application.yml reads as an eight-signal framework, and a reader has no way to tell which three are live. Worth a comment in the configuration marking the unbuilt entries, so the file states its own status.

Emitted from one site: EventFormController.onDone(), immediately after the draft order is saved.

Aggregate key order:{id}; debounce 0s, so non-squashable — one registration, one signal. The organisation is taken from the order.

onDone() is protected and invoked by the form framework at the end of a process flow, so the only entry point is the registration wizard.

Emitted from two sites.

Both are correctly guarded. OrderServiceEx emits only on a genuine PENDING → PAID transition, captured before the patch is applied, so a gateway delivering its callback twice does not signal twice. PaymentService returns early when the order is already PAID, giving the same idempotency.

Verified in event-stage on 2026-09-01: PATCH /api/orders/participant/36114 with {"status":"PAID"} produced signal 1500 — PAYMENT_COMPLETED, Order/36114, organisation 9 — with processAfter equal to createdAt and COMPLETED 272 ms later.

Emitted from one site: RaceResultServiceEx.publishResultSetChangedEvent, reached only from RaceResultServiceEx.save(RaceResult) — the entity overload — and deleteAll(Set<RaceResult>).

Aggregate key series:{id} where a series exists, otherwise null, which deliberately makes the signal non-squashable rather than collapsing unrelated result sets under a series:null key. Debounce 60s — the only non-zero window in the framework, and therefore the only signal that exercises squashing.

Three of the gaps above share one cause, and it is worth naming because it will recur.

An *Ex service extends a generated service and adds an entity-level method that emits. The generated DTO-level methods are inherited unchanged and do not emit. The REST resource calls the DTO methods. The emitting overload is never reached from the web layer.

This is invisible at the call site: orderService.save(dto) and raceResultService.save(entity) read identically and resolve to different methods with different behaviour. It cannot be caught by reading the resource, only by checking which overload resolves.

Separating scope from defect, so the list above can be acted on rather than merely absorbed.

Suggestions, not yet implemented:

Covers the three declared signal types as at develop ecfa626f. It is a point-in-time trace of work in progress and will drift as both endpoints and emitters are added; treat a discrepancy between this page and the code as a defect in the page until proven otherwise. As each further signal type is built, extend the map in the same shape — emit sites, entry points, then the silent siblings.