mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-08-07 01:14:14 +00:00
Anso
48cebf9501
* fix: bind deploy progress, request, and health gate to the captured node A deploy/update/install/git-apply re-read the active node from localStorage independently at three points: the progress WebSocket at mount, the POST at call time, and the health-gate poll. If the active node changed between the click and any of those, the operation, its live output, and its health verdict could target different nodes, and the socket and POST splitting across nodes broke output streaming. Capture the operation's node once when it starts and thread it through every leg. A new nodeId option on apiFetch overrides the active-node read, the progress terminal takes a nodeId prop for its socket URL, the health gate polls on the captured node, and a failed gate records its recovery entry only on the node it ran on. The surface, the request, and the gate now always agree. * fix: scope failed-gate recovery to the file list's node and harden node targeting Addresses review findings on the captured-node binding: - Track the node the stack file list was fetched for (filesNodeId) and record a failed gate's recovery entry only when it matches the gate's node. This closes a race where switching back to the gate's node could match a same-named stack from the previous node's still-loaded list before the new list lands, keying the record to the wrong file and blocking the correct one. refreshStacks now carries a sequence token so an out-of-order resolution cannot leave files and filesNodeId inconsistent. - Make an explicit apiFetch nodeId authoritative over a caller-supplied x-node-id header. - Add the missing stack-logs nodeId cases (null, and active-node fallback) to the terminal tests.
45 lines
2.0 KiB
TypeScript
45 lines
2.0 KiB
TypeScript
import { useDeployFeedback } from '@/context/DeployFeedbackContext';
|
|
import { useDeployFeedbackStyle } from '@/hooks/use-deploy-feedback-style';
|
|
import TerminalComponent from './Terminal';
|
|
import { DeployFeedbackModal } from './DeployFeedbackModal';
|
|
import { DeployFeedbackPill } from './DeployFeedbackPill';
|
|
|
|
export function DeployFeedbackPortal() {
|
|
const { panelState, minimized, setMinimized, bannerActive, onTerminalReady, onTerminalError, onMessage } = useDeployFeedback();
|
|
const [style] = useDeployFeedbackStyle();
|
|
|
|
return (
|
|
<>
|
|
<DeployFeedbackModal
|
|
isMinimized={minimized}
|
|
onMinimize={() => setMinimized(true)}
|
|
/>
|
|
{/* The pill is the minimized surface. In Modal style it shows whenever the
|
|
modal is minimized. In Inline style the in-page banner is the surface,
|
|
so the pill only fills in when the banner is not covering the session:
|
|
an App Store install, after navigating away from the stack, or a failed
|
|
op the banner steps aside for. This keeps a click-through to the log in
|
|
every case without ever overlapping the banner. */}
|
|
<DeployFeedbackPill
|
|
isVisible={panelState.isOpen && minimized && (style === 'modal' || !bannerActive)}
|
|
onExpand={() => setMinimized(false)}
|
|
/>
|
|
{/* Inline style streams without the modal: the modal owns the terminal in
|
|
Modal style, but in Inline style the modal stays closed, so mount the
|
|
single progress terminal here (hidden) to feed logRows to the banner.
|
|
Exactly one terminal owns the per-session socket at a time. */}
|
|
{style === 'inline' && panelState.isOpen && (
|
|
<div aria-hidden className="h-0 overflow-hidden">
|
|
<TerminalComponent
|
|
nodeId={panelState.nodeId}
|
|
deploySessionId={panelState.deploySessionId}
|
|
onReady={onTerminalReady}
|
|
onError={onTerminalError}
|
|
onMessage={onMessage}
|
|
/>
|
|
</div>
|
|
)}
|
|
</>
|
|
);
|
|
}
|