#6854 established the contract for announcing an entity change: hand the topic to the WRITE (save(entity, topic), update(entity, topic, extraEvents), updateProperties(id, values, topic), ...), so the row and its event commit or roll back together and a briefly-down broker delays the event instead of losing it. Its guide text states the doctrine: "Announce an entity change through its repository, not by publishing next to it."
The generated glue still ships the pre-outbox idiom - a targeted write followed by a bare Producer.sendToTopic beside it. Each site is a live instance of #6816's failure class (row committed, event lost forever, downstream reactions silently never run), now also a contradiction of the platform's own doctrine. Inventory on current master (template-application-events-java events/ unless noted):
Fix: substitute the outbox write - updateProperties(id, values, "<topic>") - for the write-then-publish pairs; the post-commit re-read (which a concurrent write can move) disappears with it, since the outbox payload is the row as the transaction left it, read back on the write's own connection.
The -rekeyed pair is the one non-trivial site: ONE targeted write must record TWO events (the pre-write snapshot naming the vacated group, the written row naming the joined one), and only update(entity, topic, extraEvents) accepts extra events today. The targeted path needs the same capacity - updateProperties(id, values, topic, extraEvents) (or accepting explicit DomainEvents) - so the rekey signals ride the outbox too.
Follow-up to #6854 / #6816; touches the outputs of #6836, #6841, #6845.
#6854 established the contract for announcing an entity change: hand the topic to the WRITE (
save(entity, topic),update(entity, topic, extraEvents),updateProperties(id, values, topic), ...), so the row and its event commit or roll back together and a briefly-down broker delays the event instead of losing it. Its guide text states the doctrine: "Announce an entity change through its repository, not by publishing next to it."The generated glue still ships the pre-outbox idiom - a targeted write followed by a bare
Producer.sendToTopicbeside it. Each site is a live instance of #6816's failure class (row committed, event lost forever, downstream reactions silently never run), now also a contradiction of the platform's own doctrine. Inventory on current master (template-application-events-javaevents/unless noted):Resolve.java.template-updateProperty+ re-read + publish-transitioned(added by Automatic register lookup reaches the constructs bound to its transition #6836; Fix discarding identification and audit #6841 carries it forward in the two-writes refactor)Generate.java.template- thesourceStatus:completion hook:updateProperty+ publish-transitionedSetField.java.templateTransition.java.templateStepEvent.java.templatetemplate-application-dao-java data/Repository.java.template- the targeted-write-rekeyedPAIR (fix(intent): re-parenting repairs both sides, from every write path #6845): two bare publishes surviving inside the very file fix(data): an entity event is recorded with its write, not published after it (#6816) #6854 convertedFix: substitute the outbox write -
updateProperties(id, values, "<topic>")- for the write-then-publish pairs; the post-commit re-read (which a concurrent write can move) disappears with it, since the outbox payload is the row as the transaction left it, read back on the write's own connection.The
-rekeyedpair is the one non-trivial site: ONE targeted write must record TWO events (the pre-write snapshot naming the vacated group, the written row naming the joined one), and onlyupdate(entity, topic, extraEvents)accepts extra events today. The targeted path needs the same capacity -updateProperties(id, values, topic, extraEvents)(or accepting explicitDomainEvents) - so the rekey signals ride the outbox too.Follow-up to #6854 / #6816; touches the outputs of #6836, #6841, #6845.