#6896 fix: Add deterministic error clearing for FAIL_AFTER_EXECUTABLE_NODES_COMPLETE policy Pull request opened by andreahlert Summary This PR addresses the determinism concern raised by @hamersaw in #4624 regarding error clearing behavior when multiple nodes fail with

FAIL_AFTER_EXECUTABLE_NODES_COMPLETE

policy. The Problem When multiple nodes fail, we want to preserve only one error to reduce etcd state size. The original implementation in #4624 would clear errors during iteration, but didn't account for the fact that Go map iteration order is non-deterministic. This could cause ALL errors to be cleared if iteration order varied between reconciliation rounds: 1. Round 1: Iterate [node-a, node-b] - clear node-a's error, keep node-b's 2. Round 2: Iterate [node-b, node-a] - node-b has error, clear it, then node-a has no error anymore The Solution Add a nil check before considering a node as having a "new" failure: if nodeStatus.GetExecutionError() != nil { if nodeStatusWithError != nil && !c.enableCRDebugMetadata { nodeStatusWithError.ClearExecutionError() } nodeStatusWithError = nodeStatus } Once an error is cleared, that node won't be re-processed in subsequent rounds, ensuring determinism regardless of iteration order. Changes • Add

ClearExecutionError()

method to

MutableNodeStatus

interface • Implement

ClearExecutionError()

in

NodeStatus

struct • Add nil check in

handleDownstream

before error clearing • Add comprehensive unit tests validating the deterministic behavior Test Plan • Unit tests for

ClearExecutionError()

method • Test that only the last error is preserved when multiple failures occur • Test that clearing already-nil errors is a no-op • All existing node controller tests pass Related Issues • Fixes part of #4569 (Reduce etcd state for large workflows) • Addresses determinism concern in #4624 flyteorg/flyte