Recent chats
ASKGEEZ Q&A GUIDETechnology & devices

How can I show partial results when only some requests succeed?

Quick answer

Treat each independent request as its own outcome instead of making the whole batch succeed or fail together. In JavaScript, Promise.allSettled() returns a fulfilled or rejected outcome for every input, in input order; map each outcome back to its item, then show successes alongside clearly labeled failures. [S1] Mark the overall view as partial if any item failed, and explain which items need attention.

LET’S WORK THROUGH IT

The question, the details, the next step.

Question

I’m requesting information for several items at once. If one request fails, how can I keep the successful results instead of showing one batch error?

Geez

Handle the requests as independent outcomes. In JavaScript, Promise.allSettled() waits for every input promise and returns one outcome per input, in input order, with a status of "fulfilled" or "rejected". A fulfilled outcome has a value; a rejected one has a reason. [S1] That makes it suitable when you want to retain successes and report failures item by item. By contrast, Promise.all() rejects if any input rejects, so it is less suited to this particular partial-results display. [S2]

Keep the item identity alongside its request. The outcome array follows input order, not completion order, but the API does not attach your application’s item name for you. [S1] For example, if your input list is North, Central, and South, keep that list available and pair each returned outcome with the corresponding name. Then the interface can say which item succeeded or failed rather than showing an unexplained error.

Follow-up question

What should the per-item data shape look like, and how do I avoid showing technical error details to the reader?

Geez

Use a small outcome model with a stable item identifier, a display label, a status, and either a result or a user-facing explanation. For example, this is an illustrative shape—not a required API format:

[
  { id: "north", label: "North", status: "success", result: "[result]" },
  { id: "central", label: "Central", status: "failed", message: "Could not load this item." }
]

Map promise outcomes into that shape in your application. Keep the raw rejection reason available only where your error-handling code needs it; choose an understandable message for the interface. The cited JavaScript documentation defines the promise outcome fields, but it does not prescribe your data model, error wording, or display design. [S1]

Follow-up question

How can I make it obvious that the whole screen is incomplete while still showing the results that did load?

Geez

Use an overall status as well as per-item statuses. If at least one item failed, label the batch “Partial results” or “Some items could not be loaded.” Keep successful items visible and list each failed item by name with a concise explanation. Don’t label the entire batch simply “Failed” if useful results are present; that can hide the distinction between completed and unsuccessful work.

A hypothetical rendering for three items could be:

Partial results — 2 of 3 items loaded
North — Loaded: [result]
Central — Could not load this item.
South — Loaded: [result]

The count and names here are placeholders for values your application calculates. The promise methods provide outcomes, not a ready-made completeness label or a user-interface design; your application must decide how to summarize them. [S1] This pattern also doesn’t establish why a particular request failed or guarantee that retrying it will work.

Follow-up question

What should I check before shipping this, especially when results can finish in a different order?

Geez

Check that every outcome is paired with the correct input item, even when requests finish at different times. Promise.allSettled() returns outcomes in input order regardless of completion order, but that only helps if the input-to-item mapping is preserved. [S1] Also verify the all-success case, the all-failure case, and a mixed case. For the mixed case, confirm that successful values remain visible, failures name the affected items, and the overall label says results are partial.

A practical rule is: present what succeeded, identify what did not, and avoid implying that the returned results are complete when they are not.

A practical checklist

  • Use Promise.allSettled() when independent requests should each report an outcome.

  • Keep a stable item ID or label paired with every request.

  • Render each success and failure separately, with a plain-language failure message.

  • Show an overall partial-results label whenever at least one item failed.

  • Check all-success, all-failure, and mixed outcomes, including different completion orders.

A few more useful answers

Does `Promise.allSettled()` return results in the order requests finish?

No. It returns one outcome per input in input order, regardless of completion order. Preserve the input-to-item mapping so each outcome is shown beside the right item. [S1]

Does `Promise.allSettled()` decide what the user-facing error should say?

No. It reports a rejected outcome and its reason, but your application chooses the message and how to display it. [S1]

When is `Promise.all()` a poor fit for partial results?

When you need the combined outcome to retain each independent success and failure: Promise.all() rejects if any input rejects, while Promise.allSettled() reports every outcome. [S2] [S1]

Sources

References used for this guide.

  1. [S1] Promise.allSettled() — JavaScript | MDN
    developer.mozilla.org · Checked
  2. [S2] Promise.all() — JavaScript | MDN
    developer.mozilla.org · Checked

YOUR QUESTION. YOUR DETAILS.

Let’s work through your situation.

Get a tailored answer or help with your next task. Starts at $1, with a quote before you pay.

Ask your own question
← Back to Geez at Work