berg8201 opened a new issue, #7274:
URL: https://github.com/apache/incubator-kie/issues/7274
Summary
On the unmodified Apache KIE/Kogito 10.2.0 runtime, a successful manual
retry after an async Service Task exhausts its automatic retries executes the
integration again and reaches the normal EndNode, but the process instance
remains ACTIVE. The original persisted AsyncEventNodeInstance remains in the
runtime node collection. With a synchronous Call Activity, the parent also
remains ACTIVE waiting for child completion. Starting the child directly
reproduces the same defect, without a parent.
The attached synthetic example uses the standard generated service-task
handler, with no engine patch or application-level retry implementation. The
mock service genuinely returns HTTP500 four times and HTTP200 on the manual
retry. This report concerns process completion after successful retry, not an
integration being skipped or falsely reporting success.
## Environment
- Apache KIE/Kogito: 10.2.0, released Maven BOMs and binaries.
- Quarkus: 3.27.4.1; JVM mode, Java21 (Temurin21.0.12.1 build host; Red Hat
OpenJDK21 runtime).
- PostgreSQL16.8; JDBC process persistence; embedded Data Index JPA;
Embedded Jobs with VertxJobScheduler and JPAJobStore.
- OpenShift Local/CRC2.64.0, OpenShift4.22.14, one application replica,
1CPU/2Gi, ActiveProcessorCount2.
- Maven3.9.16 on Windows11 host. No GraalVM/native-image build.
- Jobs configuration: retryMillis=300, maxNumberOfRetries=3 (four initial
attempts).
Current main and later releases have not been tested. The attachment
contains source code and run instructions only; recorded runtime data and
dependency manifests are not included.
## Model
MainWorkflow: start -> synchronous InvokeChildWorkflow (wait for completion)
-> continuation -> normal end.
ChildWorkflow: start -> set context -> async Java Service Task
UpdateExternalRecord -> synchronous parallel split -> two empty branches ->
join -> normal end.
The split/join is entirely after the async task. Healthy execution of this
exact model completes both processes. The standalone child is sufficient to
reproduce the completion defect. Diagnostic endpoints only read internal nodes
and record lifecycle events; they do not change retry behavior.
## Reproduction
The ZIP contains a Maven application, synthetic HTTP mock, four BPMN models,
read-only diagnostics, a Node.js driver, local PostgreSQL Compose configuration
and detailed commands in reproducer/README.md. No CRC credentials or cluster
access is required to build it.
1. Start the app against a fresh isolated PostgreSQL database.
2. Set the mock to HTTP500 for a new unique business key.
3. Start MainWorkflow (or ChildWorkflow directly).
4. Wait for four actual HTTP500 calls and the original job to reach ERROR
with retries=3. The child is ERROR; the parent waits ACTIVE.
5. Change the mock to HTTP200.
6. Invoke the same backend mutation used for Console retry:
```graphql
mutation { ProcessInstanceRetry(id: "<child-instance-id>") }
```
7. Observe the fifth real HTTP request returning200, the replacement work
item/Join/EndNode leaving, and the new job becoming EXECUTED.
8. Read the child runtime nodes and process/index states. The original
AsyncEventNodeInstance remains; the child and its waiting parent remain ACTIVE
with no completion timestamp. A later read confirms the same residue.
## Expected
A successful manual retry resumes the failed activity and allows normal
process completion once all legitimate work has finished. A waiting Call
Activity receives child completion and its parent can continue and complete.
Obsolete async continuations should not block completion.
## Actual and controls
| Case | Actual mock HTTP results | Process outcome |
| --- | --- | --- |
| Healthy async child through parent | 200 | Both COMPLETED |
| Healthy synchronous child through parent | 200 | Both COMPLETED |
| Async child through parent, exhausted retries then manual recovery |
500,500,500,500,200 | Child and parent ACTIVE after EndNode exit |
| Standalone async child, same manual recovery | 500,500,500,500,200 | Child
ACTIVE after EndNode exit |
These four cases reproduce on the tested KIE 10.2.0 runtime. Additional
original KIE controls: automatic recovery after500,500,200 completes; manual
retry while the mock still returns500 makes four more actual calls and leaves
another async continuation. Initial synchronous failures roll back rather than
producing the same persisted async state.
In the nested KIE case, the old job is ERROR/retries3/executionCounter0, and
the replacement job is EXECUTED/retries0/executionCounter1. The remaining
internal async node has the old job's ID. No legitimate user task, signal wait
or parallel branch remains in the child.
The Management API nodeInstances response is [] because that endpoint lists
WorkItems; it is not proof that all internal runtime nodes are gone. The
included read-only diagnostic endpoint exposes these internal nodes when the
reproducer is run.
## Source-backed diagnosis (requesting maintainer confirmation)
Our reading of the released10.2.0 code is:
1. ProcessInstanceRetry reaches ProcessError.retrigger in
AbstractProcessInstance.
2. The recorded failed WorkItem node instance ID is absent after rollback,
while the original persisted async wrapper has a different ID.
3. Looking up the node by definition creates a replacement, which is
wrapped/scheduled for async execution.
4. The successful replacement removes itself, but the original wrapper is
still in the runtime node collection.
5. WorkflowProcessInstanceImpl.canComplete rejects completion while this
node remains. No child completion event reaches the parent.
This is a diagnosis for review, not an upstream-confirmed resolution. No
patch is included or required for reproduction. We are not proposing that the
runtime force COMPLETED or change normal end semantics.
## Related reports checked
- https://github.com/apache/incubator-kie-issues/issues/2179 and runtime PR
https://github.com/apache/incubator-kie-kogito-runtimes/pull/4136 concern
wrong/nonexistent failed async node IDs. PR4136 is already listed in the10.2.0
release notes; our problem still reproduces in10.2.0:
https://github.com/apache/incubator-kie-kogito-runtimes/releases/tag/10.2.0 .
- https://github.com/apache/incubator-kie-issues/issues/2171 concerns job
rescheduling reporting EXECUTED without executing the node, leaving the process
ERROR. Here the supported process retry really executes the service and reaches
end, leaving ACTIVE.
- https://github.com/apache/incubator-kie-issues/issues/2339 concerns an NPE
while retriggering a Call Activity. This reproduction also fails without any
Call Activity.
- https://github.com/apache/incubator-kie-issues/issues/2311 concerns job
retry failing when the scheduler transaction rolls back. Here the manual
replacement executes successfully.
No exact duplicate or verified supported workaround was identified in our
search; this is not proof none exists.
## Questions for maintainers
1. Is this an existing known issue, or a separate lifecycle defect?
2. Is there a released fix or a supported retry/recovery path that handles
the persisted continuation correctly without engine modifications?
3. If fixed upstream, which release/commit includes the fix, and does it
only prevent new cases or also recover already ACTIVE instances?
4. Can the standalone reproducer be used as a regression test?
No supported workaround is claimed. We intentionally preserve stuck
instances and avoid database edits, forced completion or cancellation as a
recommended recovery procedure.
[kie-async-manual-retry-report.zip](https://github.com/user-attachments/files/34468799/kie-async-manual-retry-report.zip)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
