logging-and-error-reporting

Guides log level selection and Sentry error reporting in the Warp Rust codebase.

64.7k|5.5k|Updated Jul 8, 2021
One-click install
npx skills add https://github.com/warpdotdev/warp --skill logging-and-error-reporting
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: logging-and-error-reporting
Source: https://github.com/warpdotdev/warp/tree/main/.agents/skills/logging-and-error-reporting
Command: npx skills add https://github.com/warpdotdev/warp --skill logging-and-error-reporting

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

In the Warp codebase, choosing between log::* levels and report_error! incorrectly leads to missed Sentry issues, fragmented error grouping, double-reported failures, and leaked sensitive data in logs. This Skill codifies the exact decision rules so logging and error reporting stay consistent and actionable.

Core Features & Use Cases

  • Log level selection: Defines when to use error!, warn!, info!, debug!, and trace! based on fault source, volume, and Sentry breadcrumb behavior.
  • Sentry reporting with report_error!: Explains static grouping messages, typed error chains via .context(), extra: blocks, report_if_error!, and ReportErrorLogMode::OncePerRun throttling.
  • Sensitive data handling: Covers safe_* macros (safe_error!, safe_warn!, etc.) so verbose detail stays in dogfood builds and never ships to release-channel logs or Sentry.
  • Use Case: When reviewing a PR that adds log::error!("Failed to sync: {e:#}") for an actionable failure, use this Skill to rewrite it as report_error!(e.context("Failed to sync")) so it becomes a tracked Sentry issue with a stable fingerprint.

Quick Start

Ask the AI to review your new Rust error handling code and choose the correct log level or report_error! form following the Warp logging guidelines.

Frequently Asked Questions about logging-and-error-reporting

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I report an error to Sentry in the Warp codebase?

Use the report_error! macro with a static grouping message and a typed error chain, such as report_error!(anyhow::Error::new(e).context("Failed to read persisted data")). Only report_error! and panics create Sentry issues; log::error! is only a breadcrumb.

When should I use report_error! vs log::error! in Rust?

Use report_error! for actionable failures an engineer should fix, like violated invariants or critical subsystem failures. Use log::error! for genuine failures caused externally that are not bugs in your code, since it only becomes a Sentry breadcrumb.

Why does log::error! not create a Sentry issue?

The SentryLogger filter converts Error, Warn, and Info log records into breadcrumbs only, and drops Debug and Trace entirely. Only report_error! and panics capture structured Sentry events, so log::error! never pages anyone.

How do I keep sensitive data out of logs and Sentry?

Use the safe_* macros such as safe_error! with a safe: arm for release channels and a full: arm for dogfood builds. Never log secrets, tokens, or user content at Info level or above, since those breadcrumbs are uploaded to Sentry.

Why does my Sentry error fragment into many separate issues?

Interpolating variable data like ids or paths into the report_error! message changes the fingerprint on every occurrence, splitting one error into many groups. Keep the message static and put instance data in .context() or an extra: block.

When should I use a typed error enum instead of anyhow?

Prefer a thiserror enum with ErrorExt and register_error! when callers branch on failures or when variants have mixed actionability for Sentry. Default to anyhow when errors are only propagated with .context() to a sink that reports them.