Skip to content

I can't resolve an incident caused by the input collection for a sequential multi-instance #6952

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
saig0 opened this issue May 4, 2021 · 2 comments · Fixed by #7118
Closed
Assignees
Labels
kind/bug Categorizes an issue or PR as a bug scope/broker Marks an issue or PR to appear in the broker section of the changelog severity/mid Marks a bug as having a noticeable impact but with a known workaround

Comments

@saig0
Copy link
Member

saig0 commented May 4, 2021

Describe the bug
The process instance is stuck after resolving an incident of a sequential multi-instance subprocess.

The sequential multi-instance subprocess iterates over an input collection with more than one element. The value of the input collection is modified (e.g. change the type of the variable) before the first inner instance is completed (e.g. by completing a job/service task). If the inner instance is completed then an incident is created.

image

I can fix the input collection variable and resolve the incident. But the process instance doesn't continue. It doesn't create a new inner instance for the next element in the input collection.

image

To Reproduce

  1. deploy a process with a sequential multi-instance subprocess that defines
  • an input collection = items
  • an input element item
  1. create an instance with variables {"items":[1,2,3]}
  2. await until the service task in the subprocess is activated
  3. set the value of the variable items to "not a list" (some value that is not a list)
  4. complete the job
  5. await until an incident is created
  6. set the value of the variable items back to {"items":[1,2,3]}
  7. resolve the incident
  8. verify that the process instance doesn't continue

Expected behavior
The process instance continues and creates a new inner instance for the next element in the input collection after the incident is resolved.

Log/Stacktrace
No log or stacktrace.

Environment:

  • OS: Camunda Cloud
  • Zeebe Version: 1.0.0-alpha7
  • Configuration:
@saig0 saig0 added kind/bug Categorizes an issue or PR as a bug scope/broker Marks an issue or PR to appear in the broker section of the changelog Impact: Usability severity/mid Marks a bug as having a noticeable impact but with a known workaround labels May 4, 2021
@korthout korthout self-assigned this May 18, 2021
@korthout
Copy link
Member

No fix, but here's a failing test for it: 8afdf04

@korthout
Copy link
Member

korthout commented May 18, 2021

I can fix the input collection variable and resolve the incident. But the process instance doesn't continue.

@saig0 I think it was not really possible to resolve this incident. Somehow it writes resolved, but then it also rejects the resolve command.

C INCIDENT           RESOLVE        - #43-> -1 K16 - K16
E INCIDENT           RESOLVED       - #44->#43 K16 - EXTRACT_VALUE_ERROR Expected result of the expression 'items' to be 'ARRAY', but was 'STRING'.,  @"task"[K11] in <process "multi-task"[K05]>
R INCIDENT           RESOLVE        - #45->#43 K16 - K16 !NOT_FOUND (Expected to resolve incident with element instance 2251799813685259, but element instance not found)

This problem originates from the task having completed while the incident was created:

C PROC_INST          COMPLETE       - #36->#34 K11 - SERVICE_TASK "task" in <process "multi-task"[K05]>
E PROC_INST          COMPLETING     - #37->#36 K11 - SERVICE_TASK "task" in <process "multi-task"[K05]>
E PROC_INST          COMPLETED      - #38->#36 K11 - SERVICE_TASK "task" in <process "multi-task"[K05]>
E INCIDENT           CREATED        - #39->#36 K16 - EXTRACT_VALUE_ERROR Expected result of the expression 'items' to be 'ARRAY', but was 'STRING'.,  @"task"[K11] in <process "multi-task"[K05]>

The COMPLETED should not have been written, but we should also not write RESOLVED and reject RESOLVE at the same time. I think these are 2 different issues.

@ghost ghost closed this as completed in 95562bd May 27, 2021
ghost pushed a commit that referenced this issue May 28, 2021

Partially verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
We cannot verify signatures from co-authors, and some of the co-authors attributed to this commit require their commits to be signed.
7137: [Backport stable/1.0] Support resolving incidents created by parent processors when child is completing r=korthout a=github-actions[bot]

# Description
Backport of #7118 to `stable/1.0`.

relates to #6952

Co-authored-by: Nico Korthout <nico.korthout@camunda.com>
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes an issue or PR as a bug scope/broker Marks an issue or PR to appear in the broker section of the changelog severity/mid Marks a bug as having a noticeable impact but with a known workaround
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants