Portal Community

resetExecutionStore Implementation

resetExecutionStore: () => set({
    executionId       : null,
    status            : null,
    nodeStatuses      : {},
    logs              : [],
    selectedNodeId    : null,
    nodeInspectorData : null,
    startedAt         : null,
    completedAt       : null,
    durationMs        : null,
    errorMessage      : null
})

When to Call It

// Call resetExecutionStore BEFORE starting a new execution
async function handleRunWorkflow() {
    // 1. Reset both stores
    useExecutionStore.getState().resetExecutionStore();
    useDesignerModeStore.getState().exitExecutionMode();

    // 2. Start the execution
    const { executionId } = await processApiClient.startExecution(processId);

    // 3. Enter execution mode
    useDesignerModeStore.getState().enterExecutionMode(executionId);
    useExecutionStore.getState().setExecutionId(executionId);

    // 4. SignalR events begin populating the store in real time
}

When NOT to Call It

ScenarioCall resetExecutionStore?
User clicks Run (new execution)Yes — clear previous run data
User opens a past executionYes — clear current run data before bulk-loading past data
User switches tab within the Observer PanelNo — tab switch should not clear data
User resizes the panelNo — panel UI change only
Node status update arrives for current runNo — update in place, do not reset

Clearing on Navigation Away

// When user navigates away from the canvas (e.g., to a different module),
// call reset to free memory occupied by large log arrays
useEffect(() => {
    return () => {
        useExecutionStore.getState().resetExecutionStore();
        useDesignerModeStore.getState().exitExecutionMode();
    };
}, []);
forgetting to reset causes log contamination. If a user runs the workflow twice without a reset, the logs array accumulates entries from both runs — the Logs tab will show mixed output from two different executions. Always reset before starting a new execution.