Igor Dianov

@slamkalukas Thank you for your question. Based on my understanding of the current behavior, the second task should have the variable propagated from the previous task completion into the scope...

@bahurski-ivan Thank you for contribution. I can also backport it into `0.4.x` maintenance branch..

@bahurski-ivan, @rtmkv, @vporoxnenko Thank you for contribution. I can also backport it into `0.4.x` maintenance branch.

Using JPA for GraphQL Queries is a tricky business to make it work around transactional boundaries with lazy JPA proxy initializations for entity attributes. You can take a look at...

@bijgu1997 Thanks for the report. Please, create a PR with the reproducer test case, so I can debug it and fix the problem

This PR https://github.com/introproventures/graphql-jpa-query/pull/367 should fix it. I can backport it to maintenance branch, but I need the integration test included with the fix.

The mutations are outside the scope of the query side covered by this project. It is best to use Spring GraphQl/Data to implement custom mutation code and business logic.

@salaboy I have not touched any part of complete task variables payload. As I remember, the TaskRuntime uses TaskService.complete(taskId, variables, false) to not propagate complete variables payload in the process...

@salaboy The IT test created by @CTI777 passes with green colors. The problem is likely to be related to the implementation of the `CompeteTaskCmd` command invoked from `TaskService.complete` via `TaskRuntime.complete`...

> Hi @igdianov , i have updated the code , i think this change addresses your concern , Thanks :) Can you add test coverage for it, please? Thanks!