Summary
Client-Java topic subscriptions are non-durable, so every event published while a subscription is down is silently lost - and that window opens on every restart AND on every republish of a project, because the handler set is torn down and re-registered. The producer meanwhile sends PERSISTENT messages - paying for persistence a non-durable topic subscriber cannot collect.
Found by static source review against origin/master (1dc87fb505).
Where
ListenerClassConsumer.java:270-272 - session.createTopic(destinationName) + session.createConsumer(destination). createDurableSubscriber / setClientID appear NOWHERE in the repo (git grep returns zero hits).ListenerClassConsumer.register() (192-198) calls stopExisting(fqn) first - teardown before re-subscribe on every reload.MessageProducer.java:79 - producer.setDeliveryMode(DeliveryMode.PERSISTENT);
Example scenario
An operator republishes an application at 14:32. A record created by an integration at 14:32:01 lands in the teardown window: the repository publishes the create event, no subscriber is attached, the message is discarded. That record never triggers its process, its resolves, its postings - and is indistinguishable from one where the automation legitimately found nothing to do.
Proposed fix
Durable subscriptions with a stable client/subscription id derived from the handler's fully-qualified name (plus tenant, per the recent per-tenant subscription work in #6765/#6782), so messages published during a reload are delivered on reconnect. Needs a cleanup story for handlers that are deleted rather than reloaded, or the broker retains messages for subscriptions nobody will reconnect.
Operational mitigation until then: treat publish as a maintenance operation for event-driven apps, and provide a reconciliation path (a scheduled job that finds records stuck in a pre-automation state and reprocesses them).
Summary
Client-Java topic subscriptions are non-durable, so every event published while a subscription is down is silently lost - and that window opens on every restart AND on every republish of a project, because the handler set is torn down and re-registered. The producer meanwhile sends
PERSISTENTmessages - paying for persistence a non-durable topic subscriber cannot collect.Found by static source review against
origin/master(1dc87fb505).Where
ListenerClassConsumer.java:270-272-session.createTopic(destinationName)+session.createConsumer(destination).createDurableSubscriber/setClientIDappear NOWHERE in the repo (git grepreturns zero hits).ListenerClassConsumer.register()(192-198) callsstopExisting(fqn)first - teardown before re-subscribe on every reload.MessageProducer.java:79-producer.setDeliveryMode(DeliveryMode.PERSISTENT);Example scenario
An operator republishes an application at 14:32. A record created by an integration at 14:32:01 lands in the teardown window: the repository publishes the create event, no subscriber is attached, the message is discarded. That record never triggers its process, its resolves, its postings - and is indistinguishable from one where the automation legitimately found nothing to do.
Proposed fix
Durable subscriptions with a stable client/subscription id derived from the handler's fully-qualified name (plus tenant, per the recent per-tenant subscription work in #6765/#6782), so messages published during a reload are delivered on reconnect. Needs a cleanup story for handlers that are deleted rather than reloaded, or the broker retains messages for subscriptions nobody will reconnect.
Operational mitigation until then: treat publish as a maintenance operation for event-driven apps, and provide a reconciliation path (a scheduled job that finds records stuck in a pre-automation state and reprocesses them).