frontend-patterns/research/candidates/FailureBoundary.md

title	status	maturity	families	scales	admission
Failure Boundary	draft	hypothesis	quality composition	L5 L6	research-candidate-only

Failure Boundary

Context: a failing region should not remove unrelated useful work. Continuity competes with the cost of partial-state recovery and boundary coordination.

Proposed solution: define which failures a boundary contains, replace the affected region with usable feedback, and give recovery an explicit reset/retry contract. Keep required navigation and recoverable intent outside the failing subtree when appropriate. If containment itself fails, define the next enclosing recovery path.

Result: some work can continue; shared state corruption or global runtime failure may still cross the boundary. Resetting presentation does not undo remote effects. Never replay a write merely because a region remounted. Distinguish expected domain rejection and network errors from uncaught rendering faults.

Evidence: B05 locates React's rendering-error boundary and documented exclusions; this proposal does not claim it catches every asynchronous or event-handler error. Alternative: fail the entire task when partial continuation would mislead users. A fallback is a product state that needs accessible controls, not just logging.

Proposed relations: Mutation Outcome Tracking handles uncertain writes separately; Focus Return applies to modal dismissal, not automatically to every error replacement.

Next test: inject render, event-handler, network and fallback failures separately; record which are contained and whether retry duplicates an accepted operation.

Evidence locators: breadth review. All relations are research proposals; no canonical identity or admitted graph edges. The next test is planned, not executed. Known uses of the complete proposed contract have not been verified in this investigation.