deveops2 opened a new issue, #2393:
URL: https://github.com/apache/incubator-kie-issues/issues/2393
## Management Console: "Update Variables" reports an Error dialog although
the update succeeded
**Component:** Management Console (runtime-tools) — image
`apache/incubator-kie-kogito-management-console:10.2.0`
**Runtimes:** KIE/Kogito 10.2.0 (Quarkus 3.27.2),
`apache/incubator-kie-kogito-data-index-postgresql:10.2.0`
### What happens
Editing process variables in *Process Details* and pressing **Save** always
opens the error modal
(title "Error", buttons *Retry* / *Discard*). The modal body contains the
JSON of the **updated**
variables, i.e. the successful result of the operation.
The update itself works:
* `POST /graphql` returns HTTP 200 with
`{"data":{"ProcessInstanceUpdateVariables":"{\"id\":\"…\",\"person\":{…}}"}}`
* the runtime has the new values (`GET /{processId}/{processInstanceId}`
shows them)
* the read model catches up a few seconds later via
`ProcessInstanceVariableDataEvent`
So the dialog reports success as a failure.
### Steps to reproduce
1. Any process whose variables are part of the generated input model (i.e.
**not** tagged
`output`/`internal` — otherwise they are silently dropped, see the note
at the end).
2. Start an instance, open it in Management Console → *Process Details* →
*Variables*.
3. Change any value, press **Save**.
Expected: the variables panel shows the saved values and leaves the "unsaved
changes" state.
Actual: error modal with the updated variables as its message; the panel
keeps showing the old
values and stays dirty.
### Root cause
In the shipped bundle (`/management-console/app/index.js`) the gateway
method **throws on success**:
```js
processDetails__handleProcessVariableUpdate(e, t) {
return this.client
.mutate({ mutation: iu.HandleProcessVariableUpdateDocument,
variables: { processId: e.id, processInstanceVariables:
JSON.stringify(t, null, 2) },
fetchPolicy: "no-cache" })
.then(e => { throw JSON.parse(e.data.ProcessInstanceUpdateVariables) });
// <-- throw in .then
}
```
The caller in the Process Details component is written correctly and
therefore never reaches its
success branch:
```js
const Y = useCallback(async () =>
r.requests.processDetails__handleProcessVariableUpdate(s, u)
.then(e => { v(e); g(false); _(true); setTimeout(() => _(false), 2000)
}) // refresh values,
// clear dirty flag,
// show confirmation
.catch(e => { k(e?.message ?? "Failed to save process instance
changes.") })
, [s, r.requests, u]);
```
`k` sets the error state that opens the modal (`useEffect(() => { C &&
C.length > 0 && y(true) }, [C])`).
For comparison, the neighbouring handlers in the same class throw in the
**catch** branch, which is
the intended pattern:
```js
processDetails__handleNodeInstanceCancel(e, t) { … .catch(e => { throw
JSON.stringify(e.message, null, 2) }) }
```
Useful strings for locating the code:
`processDetails__handleProcessVariableUpdate`,
`HandleProcessVariableUpdateDocument`, `"Failed to save process instance
changes."`
### Consequences beyond the dialog
* the success handler never runs: the variables panel is not refreshed and
the unsaved-changes
state persists, so the user cannot tell the write happened;
* the modal's **Retry** button re-issues the very same (already successful)
update.
### Suggested fix
Return the parsed value instead of throwing it — this is exactly what the
caller's `.then` expects:
```js
.then(e => JSON.parse(e.data.ProcessInstanceUpdateVariables))
```
### Additional observation (possibly a separate issue)
`ProcessInstanceUpdateVariables` ends up on the runtime's *replacing*
endpoint
(`PUT /{processId}/{processInstanceId}` → `processService.update`), and that
endpoint consumes the
generated **input** model. Variables tagged `output` or `internal` are
therefore not part of the
payload the runtime accepts, while the console sends back everything it
displays. Result: pressing
Save on such an instance silently sets those variables to `null` — verified
with a process having
`person` (tag `output`) and `doublettenListe` (tag `internal`): both were
`null` afterwards, and the
mutation still returned HTTP 200. Using `PATCH`
(`processService.updatePartial`) would at least
preserve variables that are absent from the payload.
<img width="2388" height="857" alt="Image"
src="https://github.com/user-attachments/assets/00087e8a-22b6-49fb-921f-58cecedf4dc2"
/>
--
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]