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
I can set variables when failing a job #9404
Comments
Hey thanks for trying Zeebe and reaching out @waldimiro ! I think the part of Regarding adding payload to Greets |
Hi @Zelldon, I don't have a specific case. It is very important to propagate variables not only on task completition but in failure and throw cases too. As workaround I'm using zeebeClient.newSetVariablesCommand() in Job Worker... is that correct? I'm using quarkiverse zeebe.
|
For error thrown I get that, but not for job failure, since you want to retry it. Or is it to persist the intermediate state? 🤔 I think it would be good if you could reason about it a bit better, otherwise, I think the chances are quite low that this will be implemented.
It depends of course what you want to achieve, since I don't know your use case it is hard to tell. If you want to update the intermediate state sounds like a solution yes. |
Hi @Zelldon, thanks. About the failure case. Imagine that each time that a job worker is invoked, the glue code starts a task on a system. The system task has a taskId. The system task is "retryable" (thanks the taskId). In case of failure, where can I store the taskId so that by the next retry will "retryed" the correct system task associated with the Camunda process instance? With Camunda 7 was easy to store the taskId in the handleFailure variables. Perhaps you can give me more ideas... |
@Zelldon, sorry... another case about the failure case can be: for each retry I want to store the date and based on them, react the next retry... how you see there are not a specific case but give the possibility to store intermediate variables is very important (or... the solution can be through the zeebeClient.newSetVariablesCommand()... but I don't find so elegant - my opinion). |
@Zelldon excuse me... I realized that I am trying to convince you that the previous version was very good (Camunda 7 External Worker) :) I ask me why in Camunda 8 the Zeebe Job worker was not implemented based on the previous know how... |
@waldimiro thank you for your input 👍 I think it is clear that there are use cases for the variables. To sum it up, this issue is about supporting the set of variables in the job fail command. The throw error command is covered by #4337/#4080. A workaround is available: set the variables separately using a set-variables command within the job worker.
Zeebe/Camunda Platform 8 is a completely new implementation. But it is still young and doesn't contain all features from Camunda Platform 7. We will add more features eventually. Since we have limited resources, we try to prioritize the work, also based on the user input. We ask for use cases to understand the need and the usage of the feature, and to prioritize it. |
Hi, @saig0, I'd love to task this, both for newFailCommand and newThrowErrorCommand ? |
@saig0, the newFailCommand variables should be element local or process ? |
@skayliu does this answer your question? |
@saig0, According to this, UpdateVariableDocumentProcessor#L61, the |
I suggest that the job fail command sets the variables only locally. No option to set global variables. The reason is variable propagation. Similar to the job complete command, we don't set the variable globally but we propagate the variables from the related task to the upper scopes. If the task has an output mapping then the mapping is applied. If the output mappings can't be applied then we would need to create an incident. This would be more complex. So, I prefer to set the variables only locally in the scope of the task. |
Yes, I'm think so to be |
Describe the solution you'd like
I can set variables when sending a fail job command.
It should set the variables, similarly to the complete job command.
The given variable should be set as local variables in the scope of the related task. As a result, the next activated job could access the variables.
If the command would set the variables globally then it would need to apply the output mappings of the related task. Applying output mappings could raise an incident and would make the job not activatable anymore.
The text was updated successfully, but these errors were encountered: