Skip to content

Demote non-actionable report_error! calls to log levels (drive + server)#13862

Open
warp-dev-github-integration[bot] wants to merge 1 commit into
masterfrom
factory/demote-report-error-drive-server
Open

Demote non-actionable report_error! calls to log levels (drive + server)#13862
warp-dev-github-integration[bot] wants to merge 1 commit into
masterfrom
factory/demote-report-error-drive-server

Conversation

@warp-dev-github-integration

Copy link
Copy Markdown
Contributor

What & why

Audit of every report_error! call in the Warp Drive and cloud-sync files listed in the request, to reduce Sentry noise by demoting calls that don't represent actionable engineering issues. Guided by .agents/skills/logging-and-error-reporting/SKILL.md.

Only logging severity changes — no logic or control-flow changes. Demoted calls become log::warn! (a breadcrumb, not a Sentry issue); error detail is preserved via {err:#}.

Rubric used

  • Demote when the failure is caused by factors outside client-code correctness: network/RPC failures, disk/IO errors, invalid user/enterprise config, cloud-object lifecycle races, malformed data received from the server, and by-design capacity limits. These are already "not actionable" — an engineer can't act on them, and several are auto-suppressed to Warn by report_error!'s is_actionable() anyway.
  • Keep report_error! for violations of internal invariants that signal a client bug: programming guards (often paired with debug_assert!), state-machine violations, and persistence-channel failures (a broken writer channel can mean real data loss).

Demoted → log::warn! (15)

Drive:

  • drive/sharing/dialog/mod.rs (×3) — WeakViewHandle<TerminalView> upgrade failures when removing/updating/inviting session guests. Expected lifecycle race (the terminal view was dropped); already handled by early return, and the same file uses warn! for analogous handled cases.

Server:

  • server/telemetry/mod.rs — "More telemetry events in queue than the limit to persist": by-design capacity condition (we intentionally keep only the last N).
  • server/telemetry/secret_redaction.rs — failed to build the telemetry secrets regex: driven by invalid user/enterprise-configured patterns; falls back to the prior regex.
  • server/telemetry/collector.rs (×3) — telemetry disk-write failure (IO), shutdown flush failure (network; sibling timeout arm already warn!), and persisted-file removal failure (IO).
  • server/server_api.rs (×2) — notify_login POST send failure (network) and access-token retrieval failure; both best-effort in a fire-and-forget path.
  • server/server_api/ai.rs — skipping a single malformed ambient-agent task while deserializing a list (handled skip; the code comment already says "log the error and skip").
  • server/server_api/object.rs — per-object GSO conversion failure (handled skip; previously interpolated the object uid into the grouping message, fragmenting Sentry).
  • server/cloud_objects/listener.rs — websocket connection failure after retries (network; matches the sibling retry-pending arm).
  • server/cloud_objects/update_manager.rs (×2) — unparseable task_id received from the server (malformed server data) and single-object fetch failure (network).

Kept as report_error! (actionable — documented for the reviewer)

  • drive/panel.rs (×6) — owner can't be resolved for a user-initiated create: a user action silently no-ops; worth investigating.
  • drive/index.rs (×6) — current workspace missing from the dropdown list (state inconsistency) and four "wrong action / not-yet-supported" programming guards.
  • drive/workflows/modal.rs, workflow_arg_type_helpers.rs, import/{modal_body,nodes,queue}.rs — internal invariants ("both/neither id specified", "state should be path expanded", "folder id should exist", "counter should exist").
  • server/server_api/ai.rs (×3, unchanged) — unknown GraphQL enum variants ("update client GraphQL types"). These are the skill's own canonical report_error! example, are actionable (client types are stale), and are already throttled with ReportErrorLogMode::OncePerRun.
  • server/cloud_objects/update_manager.rs — persistence-channel send failure + data-consistency/programming guards (debug_assert!-paired).
  • server/sync_queue.rs (×4, unchanged) — dependency-resolution invariants that the queue's own dependency tracking should prevent.
  • server/telemetry/context.rs — serializing a fixed struct should never fail.
  • cloud_object/model/persistence.rs (×4) and cloud_object/mod.rs — persistence-channel sends + a state-machine invariant.

Validation

  • ./script/format — passes.
  • CARGO_BUILD_JOBS=1 cargo clippy -p warp -- -D warnings — passes (edits are confined to non-test source in the warp crate; unused report_error imports were removed where the last use was demoted).

Conversation: https://staging.warp.dev/conversation/7786c619-c2b7-4a6a-a410-68f473e9d7bb
Run: https://oz.staging.warp.dev/runs/019f6cfe-7a4f-7b40-97b2-68c4511d1d85

This PR was generated with Oz.

Audit of report_error! calls across the Warp Drive and cloud-sync
surfaces to reduce Sentry noise, per
.agents/skills/logging-and-error-reporting/SKILL.md. Calls that
represent conditions outside client-code correctness — network/RPC
failures, disk/IO errors, invalid user/enterprise config, cloud-object
lifecycle races, and malformed data received from the server — are
demoted to log::warn! (breadcrumb-only, no Sentry issue). Calls that
signal genuine client-side invariant violations (programming guards,
state-machine violations, persistence-channel failures) are left as
report_error!. Only logging severity changes; no logic changes.

Co-Authored-By: Oz <oz-agent@warp.dev>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant