Partial failure and total failure need separate expressions

What it is

When a page holds several independent payloads, failure can stop in one block or stop the whole page. Partitioned failure expression means the package ships both compositions: how remaining successful modules stay operable when one request fails, and how the whole page announces and offers retry when every critical payload fails. Ship only a full-screen error, and implementation will promote a single-module failure into page death. Ship only an in-module banner, and page death will be a small red line in a corner while people think the page is still alive.

This is about which layer the failure lives on, and whether that layer has its own screen in the package — not about making failure look different from an empty result. It is also not an argument about whether a local failure should disable the whole page. What is required here is that both pictures are drawn, so implementation can pick by the scope of the failure.

Why it happens

Implementation wires to screens it has. If the package holds only a full-screen error, a module-level catch has no visual destination. The cheap join is to throw to the page root, so one weather widget timing out replaces the whole dashboard, metrics already on screen included. If the package holds only an in-module banner, a root failure (auth gone, shell failed to load) has no composition; implementation will insert the banner into a layout that no longer exists, or leave the user staring at an empty shell with no retry.

The two compositions also drop actions in different places. Module retry must sit on that block so neighbors are not harmed. Page retry applies to the whole entry. The grammatical subject differs: “this pane could not update” versus “this page cannot be opened.” Mixing subjects makes people refresh the page to fix a chart, or tap module retry to fix a session that has already dropped. Scope enters code only if scope is in the composition.

Where it stops holding

A page with one payload — an article, a checkout submit — has no partial geometry to draw; total failure is that one failure. When a block refreshes silently in the background, failure often should read as “stale data still shown + a not-refreshed mark.” That is a staleness expression; do not slap an empty module error over the old data. A fatal uncertainty (a money action whose completion is unknown), even if it started as one field request, should be delivered as page-level uncertainty, because the cost of looking locally successful is higher. When a third-party embed fails beyond interception, draw a shell that says this embed is unavailable; do not pretend it can offer the same retry as a first-party module.

Applying it

• For any page with two or more independent requests, ship two frames: one with a single block failed and the rest still hittable; one with every critical request failed, entering the page-level error.
• On the module-failure frame, give reason and retry for that block only. Do not also show a page-level “reload the app.” On the page-failure frame, do not leave hittable module shells that no longer have data.
• Mark the subject of the failure on the frame (“this pane” or “this page”). Copy must not be borrowed across scopes.
• Induce both faults: break one endpoint, then break all. Overlay the two frames. If a single-endpoint failure swapped in the full-screen error, or a total failure only lit a red bar inside one card, add the missing frame to the package — do not only remap error codes.

Related

• Same group: R2.09.1 An empty state must guide the next step, not only announce absence · R2.09.2 First-use empty and emptied-after-use empty are different meanings · R2.09.4 Skeleton shapes must correspond to the content they stand in for
• Adjacent: I2.08 Load failure · R1.03 Completeness of component states
• Search terms: partitioned failure expression · partial versus total failure · module error frame