What causes "[omnidisc] stop stream failed" in tonhowtf/omniget?

Make the backend `omnidisc_stream_stop` idempotent: return Ok even when no stream is active.

[omnidisc] stop stream failed

Error message

[omnidisc] stop stream failed

What it means

stopStream invokes the backend command `omnidisc_stream_stop` to tear down an active stream. If the backend rejects (command missing, panic, or no active stream in its state), the rejection is caught and logged as this warning. The finally block still clears `publishing` and `busy`, so UI state is reset even on failure.

Solutions

Make the backend `omnidisc_stream_stop` idempotent: return Ok even when no stream is active.
Guard the frontend call: only invoke stop when `publishing !== null` or a stream is known active.
Check the backend log for the panic/error detail returned in errorText(e).
Rebuild the backend to ensure the command exists and matches the invoked name.

Example fix

// before
await invoke("omnidisc_stream_stop");
// after
if (publishing !== null) {
  await invoke("omnidisc_stream_stop");
}

Defensive patterns

Strategy: try-catch

Validate before calling

if (publishing === null) return; // nothing to stop

Try / catch

try {
  await invoke("omnidisc_stream_stop");
} catch (e) {
  console.warn("[omnidisc] stop stream failed", errorText(e));
} finally {
  publishing = null; // always reset local state
}

Prevention

Disable the stop button while busy to prevent duplicate invokes.
Make backend stop idempotent for already-stopped streams.
Re-sync UI state from omnidisc_stream_stats after a failed stop.
Log errorText(e) details to distinguish 'not active' from real backend faults.

When it happens

Trigger: Calling stopStream() when no stream is actually running in the backend, when the Rust `omnidisc_stream_stop` command panics (e.g. poisoned lock, missing publisher), or when the command is absent from the built backend.

Common situations: Double-clicking a stop button causing a second stop on an already-stopped stream; backend restarted while frontend still thinks a stream is live; version mismatch between frontend command names and Rust handlers.

Understand the failure class

Background: "API request failed": what wrapped HTTP errors from external APIs mean and how to find the real cause — this error's family across 29 libraries.

Related errors

AI-assisted analysis of tonhowtf/omniget@8600b91f42 (2026-09-12). Data as JSON: /api/errors/75276aa955470877. Report an issue: GitHub.

Appendix: source

Thrown at src/lib/stores/omnidisc-stream-store.svelte.ts:263

  lastError = null;
  try {
    const policy = currentPolicy() ?? undefined;
    publishing = await invoke<PublishStats>("omnidisc_stream_start", { args: { ...args, policy } });
    return true;
  } catch (e) {
    lastError = errorText(e);
    return false;
  } finally {
    busy = false;
  }
}

export async function stopStream(): Promise<void> {
  busy = true;
  try {
    await invoke("omnidisc_stream_stop");
  } catch (e) {
    console.warn("[omnidisc] stop stream failed", errorText(e));
  } finally {
    publishing = null;
    busy = false;
  }
}

export async function watchStream(userId: string): Promise<boolean> {
  busy = true;
  lastError = null;
  try {
    await invoke("omnidisc_stream_watch", { userId });
    if (!watchingIds.includes(userId)) watchingIds = [...watchingIds, userId];
    return true;
  } catch (e) {
    lastError = errorText(e);
    return false;
  } finally {
    busy = false;

View on GitHub (pinned to 8600b91f42)