Post RMA Repeat Failure

Pattern Description

Post-RMA repeat failure is the pattern where a system or component returns from repair or replacement, but the original symptom persists, quickly recurs, or reveals a deeper platform fault that the first RMA did not fully isolate. Across this set, repeat RMAs are often driven by intermittent failures, incomplete root-cause isolation, or a narrow component swap that misses the broader system problem.

Evidence

1. The same customer-visible failure often comes back after the first RMA. Examples include recurring segfaults, thermal throttling, hardware errors, or crashes that persisted after prior service or NTF return ([24241], [32721], [36662], [20453], [6375]) ...and 20+ more.
2. A first repair sometimes fixes one part but exposes a different underlying fault. In several cases, later validation or follow-up found another bad GPU, CPU, board, or subsystem after the original repair path appeared complete ([16007], [16702], [24241], [29692], [37862]).
3. Intermittent / NTF outcomes are high-risk for repeat failure. When Exxact or the vendor cannot reproduce the issue, the same hardware often comes back again from the customer side still failing ([41104], [20453], [29943], [7603], [9384]) ...and 10+ more.
4. Repeat cases often escalate from part swap to full-system handling. When the first RMA is too narrow, the next step is frequently prepaid repeat RMA, full-system depot work, or broader engineering validation ([16007], [24241], [32721], [6375], [37114]) ...and 10+ more.

Impact

This pattern matters because repeat RMAs multiply downtime, freight cost, and customer frustration while undermining confidence that Exxact has identified the real fault. The worst cases turn into months-long repair loops, repeated vendor returns, or disputes over who should absorb return logistics for the second or third attempt ([29692], [32721], [20453], [6375], [41104]).

Recommendations

1. Flag repeat-RMA tickets early and widen the scope. If the same symptom returns after repair, default to broader platform isolation instead of retrying the same narrow part-swap logic.
2. Treat NTF results as provisional when field evidence is strong. Capture customer reproduction conditions, reboot/load triggers, and environmental details before sending hardware back unchanged ([41104], [20453], [36662]).
3. Run post-repair validation against the original failure mode, not just generic burn-in. Repeat cases often needed workload-specific, thermal, reboot, storage, or multi-GPU validation to expose the real fault ([32721], [24241], [29692], [16007]).
4. Standardize customer handling for repeat RMAs. Several tickets show friction over return shipping, packaging, and escalation because the case was already a second pass; policy should be clear and fast for those situations ([32721], [24241], [20453], [6375]).

Referenced by

No incoming references yet.