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]

Reply via email to