Skip to content

Start the case at the event's own start event instead of by process key - #5

Merged
Klaas-Ritense merged 2 commits into
mainfrom
fix/start-case-at-the-message-start-event
Sep 16, 2026
Merged

Klaas-Ritense merged 2 commits into
mainfrom
fix/start-case-at-the-message-start-event

Conversation

@Klaas-Ritense

Copy link
Copy Markdown
Member

What

CloudEventProcessLinkListener no longer starts the process by its definition key. It now creates the case document and correlates the start message of the element the receive-cloud-event link hangs on.

Two smaller fixes come along, both in the same code path:

  • the two silent skips — no linked case definition, and a link pointing at a superseded case definition version — are now visible in the logs instead of returning quietly;
  • getMessageName errors clearly when the activity is not in the model or carries no message event definition, instead of throwing a NullPointerException.

Why

A process may have more than one start event — a plain one for the start form, and the message start event the link hangs on. Operaton enters a process started by key at whichever it considers the initial activity, which is the plain one. The event's own start event then never runs, so neither do the execution listeners that put the event on the case, and the case is created empty.

The document id is passed as the process instance business key: Valtimo resolves doc: through the process-document association and falls back to the business key while that association does not exist yet — which is the case during the start event's own listeners, since the association can only be created once the instance has an id.

This is the same fix as imap-mail-plugin 0.0.4 (e031408), ported over.

Not in scope

signalWaitingExecutions still signals every execution parked at the activity, across all cases. The imap and slack plugins narrow this down by thread, but a cloud event carries no correlation key in ReceiveCloudEventProperties, so that needs a design decision rather than a port. Left as is deliberately.

Tests

ApplicationStartIT passes, which covers the changed bean wiring (DocumentService + ProcessDocumentAssociationService). The listener has no unit tests in this repo, so the start path itself is not covered by a test — worth adding separately.

Released as 0.1.2 (backend + frontend).

Add the S3 bucket that the backend now dual-publishes to as a dependency
repository, so artifacts released there resolve without waiting for the
Maven Central sync.
…ey, release 0.1.2

A process may have more than one start event - a plain one for the start form and the
message start event the `receive-cloud-event` link hangs on - and Operaton enters a process
started by key at whichever it considers the initial activity, which is the plain one. The
event's own start event then never runs, so neither do the execution listeners that put the
event on the case, and the case is created empty.

The case is now created directly and the start message of the linked element correlated to
it, with the document id as business key so `doc:` resolves before the process-document
association exists.

Also makes the two silent skips - no linked case definition, superseded case definition
version - visible in the logs, and turns the BPMN lookup of the message name into a clear
error instead of a NullPointerException.
@Klaas-Ritense
Klaas-Ritense merged commit ae49423 into main Sep 16, 2026
5 checks passed
@Klaas-Ritense
Klaas-Ritense deleted the fix/start-case-at-the-message-start-event branch September 16, 2026 13:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant