Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug] Unhandled Stop Reason "sensitive" Crashes Agent and Stalls Telegram Polling [7 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#43607•Fetched 2026-04-08 00:16:52
View on GitHub
Comments
0
Participants
1
Timeline
25
Reactions
0
Author
dapingzuidapingzui
Participants
dapingzuidapingzui
Timeline (top)
referenced ×16cross-referenced ×7closed ×1locked ×1

When Claude API detects sensitive content and returns stop_reason: "sensitive", the pi-embedded runner crashes with "Unhandled stop reason: sensitive" error. This causes Telegram polling to stall and the agent to become unresponsive to messages.

Error Message

When Claude API detects sensitive content and returns stop_reason: "sensitive", the pi-embedded runner crashes with "Unhandled stop reason: sensitive" error. This causes Telegram polling to stall and the agent to become unresponsive to messages. 4. The following error appears in gateway logs: Unhandled stop reason: sensitive

  • Framework throws unhandled error: Unhandled stop reason: sensitive

Error Output

warn {"subsystem":"agent/embedded"} embedded run agent end: runId=803edefd-1f10-4cb1-a7f3-e0edf7b50757 isError=true error=Unhandled stop reason: sensitive error {"subsystem":"gateway/channels/telegram"} [telegram] Polling stall detected (no getUpdates for 955.5s); forcing restart. error {"subsystem":"gateway/channels/telegram"} Telegram polling runner stopped (polling stall detected); restarting in 21.24s. The pi-embedded runner's stop reason handling is incomplete. It only recognizes specific stop reasons (completed, tool_calls, error, abort) but not sensitive. /\bstop reason:\s*(?:abort|error)\b/i, /\bunhandled stop reason:\s*(?:abort|error)\b/i /\bstop reason:\s*(?:abort|error|sensitive)\b/i, /\bunhandled stop reason:\s*(?:abort|error|sensitive)\b/i

  1. Update stop reason classifier in pi-embedded runner to recognize sensitive as a valid stop reason (not an error)
  • Session file with error context available

Root Cause

The pi-embedded runner's stop reason handling is incomplete. It only recognizes specific stop reasons (completed, tool_calls, error, abort) but not sensitive.

The framework uses regex patterns to classify stop reasons:

/\bstop reason:\s*(?:abort|error)\b/i,
/\bunhandled stop reason:\s*(?:abort|error)\b/i

These patterns should be extended to include sensitive:

/\bstop reason:\s*(?:abort|error|sensitive)\b/i,
/\bunhandled stop reason:\s*(?:abort|error|sensitive)\b/i

Fix Action

Fix / Workaround

  • Severity: HIGH
  • Affected Components: Telegram channel, agent responsiveness, gateway stability
  • Impact Scope: Any agent receiving potentially sensitive user input via Telegram/Discord
  • Current Workaround: openclaw daemon restart (manual intervention required)

PR fix notes

PR #43615: fix(agent): handle "sensitive" stop reason to avoid crash and polling stall (#43607)

Description (problem / solution / changelog)

Summary

When the Claude API (or other providers) returns stop_reason: "sensitive" for content-policy rejection, the underlying pi-ai layer throws an error: Unhandled stop reason: sensitive. The pi-embedded runner only handled abort, error, and malformed_response, so this error was unhandled. The run then threw, the agent crashed, and Telegram polling stalled (e.g. "Polling stall detected (no getUpdates for 955.5s); forcing restart") until manual restart (openclaw daemon restart).

This PR treats sensitive as a normal completion: the run finishes with a short user-facing message and meta.stopReason: "sensitive", so the agent does not crash and channel polling continues.

Fixes #43607

Changes

AreaChange
src/agents/pi-embedded-runner/run.tsAfter describeUnknownError(promptError), detect errors matching (unhandled )?stop reason: sensitive (case-insensitive). Return a successful result with a single payload text ("I cannot process this request as it contains content that violates our usage policies. Please rephrase your question.") and meta: { durationMs, agentMeta, systemPromptReport, aborted: false, stopReason: "sensitive" }. No throw, so no crash and no polling stall.
src/agents/pi-embedded-helpers/failover-matches.tsAdd sensitive to the three stop-reason timeout regexes so Unhandled stop reason: sensitive / stop reason: sensitive / reason: sensitive are recognized consistently (e.g. for isTimeoutErrorMessage / classifyFailoverReason).
TestsIn pi-embedded-helpers.isbillingerrormessage.test.ts: new test "matches sensitive stop reason as timeout (#43607)" for the three message variants. In failover-error.test.ts: new test "infers timeout from sensitive stop-reason message (#43607)" for resolveFailoverReasonFromError.
DocsIn docs/concepts/model-failover.md (Cooldowns): add one sentence that the sensitive stop reason is handled separately and completes with a user-facing message without triggering failover or cooldown.

Expected behavior after fix

  • User sends content that triggers provider content-policy → API returns stop_reason: "sensitive" → pi-ai throws Unhandled stop reason: sensitive.
  • Runner catches this, returns a normal completion with the policy message and stopReason: "sensitive".
  • Agent does not crash; Telegram (and other channels) polling continues; no manual restart needed.

Testing

  • Unit: pnpm test --run src/agents/pi-embedded-helpers.isbillingerrormessage.test.ts src/agents/failover-error.test.ts — all passed.
  • Lint/format: Modified files formatted with pnpm format:fix; no new linter issues in changed files.
  • Manual: Not run; suggest testing with a channel that can trigger content-policy (e.g. Telegram) and verifying that after a "sensitive" response the agent stays up and accepts the next message.

Checklist

  • Code follows repo conventions (see CLAUDE.md / AGENTS.md).
  • Added tests for the new behavior.
  • Updated docs where relevant (model-failover).
  • No changelog entry (internal/behavioral fix; add to CHANGELOG only if maintainers prefer user-facing note).

Related

  • Issue: #43607

Changed files

  • docs/concepts/model-failover.md (modified, +3/-1)
  • src/agents/failover-error.test.ts (modified, +7/-0)
  • src/agents/pi-embedded-helpers.isbillingerrormessage.test.ts (modified, +13/-0)
  • src/agents/pi-embedded-helpers/failover-matches.ts (modified, +3/-3)
  • src/agents/pi-embedded-runner/run.ts (modified, +26/-0)
  • src/cli/daemon-cli/lifecycle.test.ts (modified, +11/-10)

PR #43625: fix(agent): handle "sensitive" stop reason to avoid crash and polling stall (#43607)

Description (problem / solution / changelog)

Summary

When the Claude API (or other providers) returns stop_reason: "sensitive" for content-policy rejection, the underlying pi-ai layer throws an error: Unhandled stop reason: sensitive. The pi-embedded runner only handled abort, error, and malformed_response, so this error was unhandled. The run then threw, the agent crashed, and Telegram polling stalled (e.g. "Polling stall detected (no getUpdates for 955.5s); forcing restart") until manual restart (openclaw daemon restart).

This PR treats sensitive as a normal completion: the run finishes with a short user-facing message and meta.stopReason: "sensitive", so the agent does not crash and channel polling continues.

Changes

AreaChange
src/agents/pi-embedded-runner/run.tsAfter describeUnknownError(promptError), detect errors matching (unhandled )?stop reason: sensitive (case-insensitive). Return a successful result with a single payload text ("I cannot process this request as it contains content that violates our usage policies. Please rephrase your question.") and meta: { durationMs, agentMeta, systemPromptReport, aborted: false, stopReason: "sensitive" }. No throw, so no crash and no polling stall.
src/agents/pi-embedded-helpers/failover-matches.tsAdd sensitive to the three stop-reason timeout regexes so Unhandled stop reason: sensitive / stop reason: sensitive / reason: sensitive are recognized consistently (e.g. for isTimeoutErrorMessage / classifyFailoverReason).

Expected behavior after fix

  • User sends content that triggers provider content-policy → API returns stop_reason: "sensitive" → pi-ai throws Unhandled stop reason: sensitive.
  • Runner catches this, returns a normal completion with the policy message and stopReason: "sensitive".
  • Agent does not crash; Telegram (and other channels) polling continues; no manual restart needed.

Testing

  • Unit: pnpm test --run src/agents/pi-embedded-helpers.isbillingerrormessage.test.ts src/agents/failover-error.test.ts — all passed.
  • Lint/format: Modified files formatted with pnpm format:fix; no new linter issues in changed files.
  • Manual: Not run; suggest testing with a channel that can trigger content-policy (e.g. Telegram) and verifying that after a "sensitive" response the agent stays up and accepts the next message.

Checklist

  • Code follows repo conventions (see CLAUDE.md / AGENTS.md).
  • Added tests for the new behavior.
  • Updated docs where relevant (model-failover).
  • No changelog entry (internal/behavioral fix; add to CHANGELOG only if maintainers prefer user-facing note).

Related

Changed files

  • docs/concepts/model-failover.md (modified, +3/-1)
  • src/agents/failover-error.test.ts (modified, +7/-0)
  • src/agents/pi-embedded-helpers.isbillingerrormessage.test.ts (modified, +13/-0)
  • src/agents/pi-embedded-helpers/failover-matches.ts (modified, +3/-3)
  • src/agents/pi-embedded-runner/run.ts (modified, +31/-0)
  • src/cli/daemon-cli/lifecycle.test.ts (modified, +11/-10)

PR #43884: fix(failover): classify z.ai network_error stop reason as retryable timeout

Description (problem / solution / changelog)

Summary

  • Add network_error to the stop-reason failover regex patterns so z.ai's non-standard finish_reason: "network_error" is classified as a retryable timeout instead of surfacing raw to the user.

Problem

When z.ai (GLM-5 and other models) encounters connectivity issues, its API returns finish_reason: "network_error". The pi-ai library's mapStopReason() doesn't handle this and throws "Unhandled stop reason: network_error". OpenClaw's failover classifier only recognizes abort, error, and malformed_response as retryable unhandled stop reasons — network_error falls through and the error is shown directly to the user.

Fix

Added network_error to the three stop-reason regex patterns in failover-matches.ts (same approach as #42292 for Gemini's MALFORMED_RESPONSE).

Related issues

  • Closes #29429 — Failover not triggered for network_error stop reason
  • Related #42149 — Gemini MALFORMED_RESPONSE finish reason crashes agent run (same pattern, fixed by #42292)
  • Related #27281 — z.ai GLM-4.7-flash fails with Unhandled stop reason: network_error
  • Related #16252 — pi-ai: Unhandled stop reason from Z.AI GLM-5
  • Related #26970 — Failover not triggered when model returns stop_reason: "error" (GLM-5 via OpenRouter)
  • Related #43607 — Unhandled Stop Reason "sensitive" crashes agent (same class of bug, different stop reason)

Test plan

  • Added test in pi-embedded-helpers.isbillingerrormessage.test.ts verifying network_error variants match as timeout
  • Added test in failover-error.test.ts verifying resolveFailoverReasonFromError returns "timeout" for the error message
  • Existing MALFORMED_FUNCTION_CALL negative test still passes (not retryable)
  • All 89 failover tests pass

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/agents/failover-error.test.ts (modified, +3/-0)
  • src/agents/pi-embedded-helpers.isbillingerrormessage.test.ts (modified, +13/-0)
  • src/agents/pi-embedded-helpers/failover-matches.ts (modified, +3/-3)

PR #20067: feat(plugins): add before_agent_reply hook (claiming pattern)

Description (problem / solution / changelog)

Summary

  • Adds a before_agent_reply plugin hook that fires after slash commands but before the LLM agent runs
  • Plugins can return { handled: true, reply } to short-circuit agent processing (forms, wizards, approval gates, etc. as plugins without touching core)
  • Uses the runClaimingHook pattern (sequential by priority, first { handled: true } wins) — same pattern as inbound_claim
  • Populates full PluginHookAgentContext including trigger, channelId, messageProvider

Motivation

Per VISION.md, core stays lean and optional capability should ship as plugins. Right now there's no way for a plugin to intercept an inbound message and return a synthetic reply before the LLM runs — anything that needs pre-LLM interception has to modify core. This hook fills that gap.

Closes #8807.

Design

Hook name: before_agent_reply

When it fires: After handleInlineActions returns kind: "continue", before stageSandboxMedia / runPreparedReply. This means /help and other slash commands still work normally, even during a plugin dialog.

Event type:

{ cleanedBody: string }  // final user message heading to LLM

Result type (claiming pattern):

{
  handled: boolean;      // true = claim this message, short-circuit the LLM
  reply?: ReplyPayload;  // synthetic reply (omit to silently swallow)
  reason?: string;       // for logging/debugging
}

Context: Full PluginHookAgentContext (agentId, sessionKey, sessionId, workspaceDir, messageProvider, trigger, channelId).

Execution: runClaimingHook — async, sequential by priority (highest first). First handler to return { handled: true } wins; remaining handlers are not called. When handled: true without reply, the message is swallowed via SILENT_REPLY_TOKEN.

Changes

FileLinesWhat
src/plugins/types.ts+21Hook name, event/result types (with handled: boolean), handler map entry
src/plugins/hooks.ts+21runBeforeAgentReply using runClaimingHook, imports, re-exports
src/auto-reply/reply/get-reply.ts+26Hook call site after inline actions, before LLM
src/plugins/hooks.before-agent-reply.test.ts+1238 tests: single claim, no hooks, first-claim-wins, swallow, decline-then-claim, all decline, error handling, hasHooks

Test plan

  • pnpm test -- src/plugins/hooks.before-agent-reply.test.ts — all 8 tests pass
  • pnpm test -- src/plugins/hooks — all 27 existing hook tests unaffected
  • pnpm test -- src/auto-reply/reply/get-reply — existing get-reply tests pass
  • pnpm oxlint / pnpm format — clean
  • pnpm tsgo — no new type errors (pre-existing upstream errors only)
  • git diff upstream/main --stat — exactly 4 files, no unrelated changes, no deletions of inbound_claim code

Changed files

  • CHANGELOG.md (modified, +1/-1)
  • docs/automation/hooks.md (modified, +2/-1)
  • docs/concepts/agent-loop.md (modified, +1/-0)
  • src/auto-reply/reply/get-reply.before-agent-reply.test.ts (added, +181/-0)
  • src/auto-reply/reply/get-reply.ts (modified, +40/-0)
  • src/plugins/hooks.before-agent-reply.test.ts (added, +123/-0)
  • src/plugins/hooks.ts (modified, +21/-0)
  • src/plugins/types.ts (modified, +21/-0)

PR #43739: fix(agents): handle stop_reason 'sensitive' gracefully (#43607)

Description (problem / solution / changelog)

Summary

  • handle Unhandled stop reason: sensitive in the embedded runner as a graceful user-facing reply instead of rethrowing, so the agent turn completes without crashing
  • add a regression test in usage-reporting.test.ts that verifies the sensitive stop-reason prompt error returns the safety-filter guidance message
  • extend failover timeout hint parsing/tests to recognize stop reason: sensitive variants and avoid leaving these unclassified in failover error helpers

Verification

  • pnpm test src/agents/pi-embedded-runner/usage-reporting.test.ts
  • pnpm test src/agents/failover-error.test.ts (currently fails in this repo with TypeError: getOAuthProviders is not a function before tests execute)
  • pnpm build

Changed files

  • src/agents/pi-embedded-runner/run.ts (modified, +34/-0)
  • src/agents/pi-embedded-runner/types.ts (modified, +2/-1)

PR #55467: fix(agents): handle stop_reason 'sensitive' gracefully (#43607)

Description (problem / solution / changelog)

Summary

When the LLM returns stop_reason: sensitive (content safety filter), the agent loop throws an unhandled error instead of returning a user-friendly message. This causes confusing error output for users who trigger safety filters.

Root Cause

The embedded runner's error handling loop had no case for the sensitive stop reason. It was handled by the catch-all error path, producing a generic error instead of a clear explanation.

Changes

  • src/agents/pi-embedded-runner/run.ts: Added SENSITIVE_STOP_REASON_RE regex to detect sensitive stop reason patterns (both bare text and JSON-stringified variants), plus a handler that returns a user-facing message: "I can't respond to that - the content was flagged by the model's safety filter."
  • src/agents/pi-embedded-runner/types.ts: Added "sensitive" to the error kind union type

Note: This is a rewrite of the closed PR #43739 which had merge conflicts after run.ts was split into multiple files.

Test

  • LSP diagnostics clean on both changed files
  • pnpm test -- src/agents/pi-embedded-runner/usage-reporting.test.ts passed

Closes #43607

Changed files

  • src/agents/pi-embedded-runner/run.ts (modified, +31/-0)
  • src/agents/pi-embedded-runner/types.ts (modified, +2/-1)

PR #56639: fix(agents): handle unhandled stop reasons gracefully instead of crashing

Description (problem / solution / changelog)

Summary

  • Wrap embedded agent stream to catch Unhandled stop reason: ... errors from the provider adapter
  • Convert crashes into structured assistant error messages so the turn surfaces as an error response
  • Covers all unknown stop reasons, not just sensitive — future-proof against new provider stop reasons
  • Wrapper becomes a harmless no-op once the upstream dependency handles them natively

Root Cause

mapStopReason() in the Anthropic provider adapter throws Unhandled stop reason: ${reason} for unknown values. When the provider returns stop_reason: "sensitive", the error bubbles through attempt.ts and crashes the agent turn, stalling Telegram polling and any other channel waiting for a response.

Change Type

  • Bug fix

Testing

Tests pass on VM covering:

  • Stream-event path with sensitive stop reason
  • Synchronous-throw path with arbitrary unknown stop reason
  • Both paths verify structured error message instead of crash

Changelog

Entry added to CHANGELOG.md under Fixes.

Fixes #43607

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/agents/pi-embedded-runner/run/attempt.stop-reason-recovery.test.ts (added, +72/-0)
  • src/agents/pi-embedded-runner/run/attempt.stop-reason-recovery.ts (added, +176/-0)
  • src/agents/pi-embedded-runner/run/attempt.ts (modified, +8/-0)

Code Example

warn {"subsystem":"agent/embedded"} embedded run agent end: runId=803edefd-1f10-4cb1-a7f3-e0edf7b50757 isError=true error=Unhandled stop reason: sensitive
error {"subsystem":"gateway/channels/telegram"} [telegram] Polling stall detected (no getUpdates for 955.5s); forcing restart.
error {"subsystem":"gateway/channels/telegram"} Telegram polling runner stopped (polling stall detected); restarting in 21.24s.

---

/\bstop reason:\s*(?:abort|error)\b/i,
/\bunhandled stop reason:\s*(?:abort|error)\b/i

---

/\bstop reason:\s*(?:abort|error|sensitive)\b/i,
/\bunhandled stop reason:\s*(?:abort|error|sensitive)\b/i

---

if (stopReason === "sensitive") {
     return {
       payloads: [{
         text: "I cannot process this request as it contains content that violates our usage policies. Please rephrase your question."
       }],
       meta: { stopReason: "sensitive", aborted: false }
     };
   }
RAW_BUFFERClick to expand / collapse

[Bug] Unhandled Stop Reason "sensitive" Crashes Agent and Stalls Telegram Polling

Summary

When Claude API detects sensitive content and returns stop_reason: "sensitive", the pi-embedded runner crashes with "Unhandled stop reason: sensitive" error. This causes Telegram polling to stall and the agent to become unresponsive to messages.

Environment

  • OpenClaw: 2026.3.8 (3caab92)
  • Platform: macOS Sonoma (arm64)
  • Node.js: v22.x
  • Reproducible: Yes (intermittently, triggered when sensitive content is processed)

Steps to Reproduce

  1. Configure OpenClaw with a Telegram channel
  2. Send a message containing potentially sensitive content (violence, explicit material, hate speech, etc.)
  3. Claude API processes the request and returns stop_reason: "sensitive"
  4. The following error appears in gateway logs: Unhandled stop reason: sensitive
  5. Telegram polling stalls with messages like: [telegram] Polling stall detected (no getUpdates for 955.5s); forcing restart
  6. Agent becomes unresponsive to new Telegram messages
  7. Manual restart required: openclaw daemon restart

Expected Behavior

  • stop_reason: "sensitive" should be handled gracefully by the framework
  • Agent should return a user-friendly message explaining the content policy
  • Telegram polling should continue normally without stalling
  • No agent crashes or service interruption
  • Subsequent messages should be processed normally

Actual Behavior

  • Framework throws unhandled error: Unhandled stop reason: sensitive
  • Pi-embedded runner crashes during message processing
  • Telegram polling enters stall state (no updates received)
  • Gateway logs show repeated restart attempts
  • Agent requires manual restart to resume service

Error Output

warn {"subsystem":"agent/embedded"} embedded run agent end: runId=803edefd-1f10-4cb1-a7f3-e0edf7b50757 isError=true error=Unhandled stop reason: sensitive
error {"subsystem":"gateway/channels/telegram"} [telegram] Polling stall detected (no getUpdates for 955.5s); forcing restart.
error {"subsystem":"gateway/channels/telegram"} Telegram polling runner stopped (polling stall detected); restarting in 21.24s.

Root Cause Analysis

The pi-embedded runner's stop reason handling is incomplete. It only recognizes specific stop reasons (completed, tool_calls, error, abort) but not sensitive.

The framework uses regex patterns to classify stop reasons:

/\bstop reason:\s*(?:abort|error)\b/i,
/\bunhandled stop reason:\s*(?:abort|error)\b/i

These patterns should be extended to include sensitive:

/\bstop reason:\s*(?:abort|error|sensitive)\b/i,
/\bunhandled stop reason:\s*(?:abort|error|sensitive)\b/i

Suggested Solution

  1. Update stop reason classifier in pi-embedded runner to recognize sensitive as a valid stop reason (not an error)

  2. Implement graceful handling for sensitive content:

    if (stopReason === "sensitive") {
  return {
    payloads: [{
      text: "I cannot process this request as it contains content that violates our usage policies. Please rephrase your question."
    }],
    meta: { stopReason: "sensitive", aborted: false }
  };
}

  3. Add logging for compliance tracking (which content types trigger sensitive blocks)

  4. Ensure polling continuity so Telegram receiver continues working after sensitive content rejection

Impact Assessment

  • Severity: HIGH
  • Affected Components: Telegram channel, agent responsiveness, gateway stability
  • Impact Scope: Any agent receiving potentially sensitive user input via Telegram/Discord
  • Current Workaround: openclaw daemon restart (manual intervention required)

Related References

  • CHANGELOG mentions handling similar "abort" stop reason in #18618 - same pattern should apply
  • This issue differs from normal errors - it's a policy rejection, not a failure
  • Similar to how content filters work in other APIs (OpenAI, Google, etc.)

Attachments

  • Gateway logs excerpt showing polling stall pattern
  • Session file with error context available

extent analysis

Fix Plan

To address the issue, follow these steps:

  • Update the stop reason classifier in the pi-embedded runner to recognize sensitive as a valid stop reason.
  • Implement graceful handling for sensitive content by returning a user-friendly message.
  • Add logging for compliance tracking.
  • Ensure polling continuity.

Code Changes

// Update stop reason classifier
const stopReasonPatterns = [
  /\bstop reason:\s*(?:abort|error|sensitive)\b/i,
  /\bunhandled stop reason:\s*(?:abort|error|sensitive)\b/i
];

// Implement graceful handling for sensitive content
if (stopReason === "sensitive") {
  return {
    payloads: [{
      text: "I cannot process this request as it contains content that violates our usage policies. Please rephrase your question."
    }],
    meta: { stopReason: "sensitive", aborted: false }
  };
}

// Add logging for compliance tracking
logger.info(`Sensitive content detected: ${content}`);

// Ensure polling continuity
// No code changes needed, as the updated stop reason handling should prevent polling stalls

Verification

To verify the fix, follow these steps:

  • Send a message containing potentially sensitive content.
  • Check the gateway logs for the presence of the user-friendly message.
  • Verify that Telegram polling continues normally without stalling.
  • Check the logs for compliance tracking entries.

Extra Tips

  • Regularly review and update the stop reason classifier to handle new types of stop reasons.
  • Consider implementing a more robust content filtering system to reduce the likelihood of sensitive content being processed.
  • Ensure that the logging mechanism is properly configured to track compliance-related events.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#autograd error#docker error#permission error#memory optimization#batch processing

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING