What causes "The model request was superseded." in Hmbown/CodeWhale?

Nothing to fix — the error is expected cancellation; ensure the caller treats it as benign

Hmbown/CodeWhale · info · Error

The model request was superseded.

Error message

The model request was superseded.

What it means

Thrown by the fetch callback passed to collectProviderModelPages when the new-thread dialog's request generation advanced or the dialog closed while model pages were still being loaded. It is a deliberate cancellation signal, not a fault: stale pagination work must stop instead of populating a dialog the user already left or re-opened.

Solutions

Nothing to fix — the error is expected cancellation; ensure the caller treats it as benign
If it surfaces as a visible error toast, catch it and return silently instead of reporting
Avoid rapid re-opening of the dialog in automation/scripts while a load is pending
Check that dialog close handlers do not trigger redundant generation bumps that cancel loads

Example fix

// before: every thrown error becomes a toast
try { await loadModels(provider); } catch (e) { showToast(e.message); }
// after: suppress expected cancellations
try { await loadModels(provider); }
catch (e) {
  if (e.message !== 'The model request was superseded.') showToast(e.message);
}

Defensive patterns

Strategy: try-catch

Validate before calling

if (generation !== app.newThreadGeneration || !dom.newThreadDialog.open) return; // bail before fetching

Try / catch

try { await loadModels(provider); } catch (e) { if (e.message === 'The model request was superseded.') return; throw e; }

Prevention

Treat superseded loads as silent cancellations
Debounce dialog open/close to avoid redundant generation bumps
Track a generation counter for every cancellable UI request
Never render results fetched under an older generation

When it happens

Trigger: The user closes the new-thread dialog or re-opens it (bumping app.newThreadGeneration) while a provider's model pages are mid-load; the in-flight api(path) then throws this error.

Common situations: User clicks away/cancels while models are loading; rapid open/close/open of the dialog; switching providers quickly, invalidating the previous provider's in-flight page fetches.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

AI-assisted analysis of Hmbown/CodeWhale@73e0f67d83 (2026-09-22). Data as JSON: /api/errors/69c7279f107f6372. Report an issue: GitHub.

Appendix: source

Thrown at crates/tui/src/runtime_web/app.mjs:1934

    }

    const modelDefault = String(preferredModel || provider.default_model || "").trim();
    if (!provider.has_model_catalog) {
      dom.newThreadModelInput.value = modelDefault;
      app.newThreadLoading = false;
      setNewThreadStatus("");
      syncNewThreadControls();
      return;
    }

    app.newThreadLoading = true;
    setNewThreadStatus("Loading models…");
    syncNewThreadControls();
    try {
      const modelEntries = await collectProviderModelPages(provider.id, async (path) => {
        const page = await api(path);
        if (generation !== app.newThreadGeneration || !dom.newThreadDialog.open) {
          throw new Error("The model request was superseded.");
        }
        return page;
      });
      if (generation !== app.newThreadGeneration || !dom.newThreadDialog.open) return;
      const seen = new Set();
      const models = [];
      for (const entry of modelEntries) {
        const id = String(entry?.id || "").trim();
        const key = id.toLowerCase();
        if (!id || seen.has(key)) continue;
        seen.add(key);
        models.push({
          id,
          image_input: ["supported", "unsupported", "unknown"].includes(entry?.image_input)
            ? entry.image_input
            : "unknown",
        });
      }

View on GitHub (pinned to 73e0f67d83)