[I] Runtime Host SSH management: a fully received frame is discarded when the SSH process times out [maka]

["Astro-Han (via GitHub)" <gi...@apache.org>]

Astro-Han opened a new issue, #3546:
URL: https://github.com/apache/maka/issues/3546

   Spun out of the review of #3419 at the author's request ([P3], not a merge blocker).
   
   ## What happens
   
   `apps/desktop/src/main/runtime-host-ssh-terminal.ts`, in `runServiceManagement`:
   
   ```ts
   managementTerminal = terminal;
   if (frame) completePresentation(terminal);          // :457 — the frame is already fully decoded here
   const result = await waitForTerminalProcess(process, {
     signal: managementInput.signal,
     timeoutMs: MANAGEMENT_TIMEOUT_MS,                 // :458-464 — throws on timeout
     timeoutMessage: 'Remote Runtime Host service management timed out',
     ...
   });
   filter.finish();
   if (frameFailure) throw frameFailure;
   if (!frame) { ... }                                 // :467 — never reached on timeout
   ```
   
   `MANAGEMENT_TIMEOUT_MS = 2 * 60_000` (`:65`).
   
   If the remote emitted its management frame and the frame decoded successfully, but the SSH process then fails to exit within two minutes (a wedged shell, a lingering child holding the pty, a stalled connection teardown), `waitForTerminalProcess` throws **before** the already-received `frame` is ever returned. The frame is discarded and the caller is told the operation failed.
   
   ## Why it matters more after #3419
   
   The caller sees a failure while the operation on the Host side may have already succeeded. Before #3419 this path carried the setup flow; #3419 routes **side-effecting credential operations** (revocation, pending-credential creation) through the same code, so the false-failure window now spans operations that changed remote state.
   
   ## Why P3 and not higher
   
   - No data loss — the Host-side effect is durable, only the local report is wrong.
   - Retry is safe: revocation is idempotent, and re-preparing replaces the pending credential.
   - **The shape pre-exists on main**; it is not introduced by #3419. Confirmed by diffing against the merge base — the identical structure is already in the setup path.
   
   ## Suggested minimal fix
   
   Once a frame has been received and decoded, a process-exit timeout should not turn the call into a failure. Either skip the process wait when `frame` is set, or catch the timeout, log a warning, and return the frame — letting the process teardown fall to the existing cleanup path.


-- 
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: commits-unsubscribe@maka.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org

Re: [I] Runtime Host SSH management: a fully received frame is discarded when the SSH process times out [maka]

["jackwener (via GitHub)" <gi...@apache.org>]

jackwener closed issue #3546: Runtime Host SSH management: a fully received frame is discarded when the SSH process times out
URL: https://github.com/apache/maka/issues/3546


-- 
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: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org