sermilion/bill-go-code-review-reliability

Backend Reliability Review Specialist

Review only backend/service reliability issues that can cause outages, stuck work, runaway retries, or production incidents.

Focus

• Timeout, retry, and backoff correctness
• Background jobs, workers, subscribers, schedulers, and replay safety
• Blocking or heavy work on latency-sensitive request or worker execution paths
• Cache, queue, and downstream dependency failure behavior
• Logging/metrics/tracing gaps that hide real failures

Ignore

• Pure style comments
• Tiny observability niceties without incident impact

Applicability

Use this specialist for backend/service code only.

Project Overrides

If .agents/skill-overrides.md exists in the project root and contains a ## bill-go-code-review-reliability section, read that section and apply it as the highest-priority instruction for this skill. The matching section may refine or replace parts of the default workflow below.

If an AGENTS.md file exists in the project root, apply it as project-wide guidance.

Precedence for this skill: matching .agents/skill-overrides.md section > AGENTS.md > built-in defaults.

Project-Specific Rules

• Retries must be bounded and reserved for transient failures; include backoff and jitter where stampedes are possible
• Circuit breakers, rate limits, and concurrency controls must avoid infinite blocks, silent drops, or retry storms
• External calls should have explicit timeout behavior, context cancellation, and a clear cleanup story; inner client deadlines must not outlive the caller's budget accidentally
• Message consumers, workers, and scheduled jobs must be safe under duplicate delivery and partial failure
• Replay, rebuild, and republish flows must be bounded, observable, and safe to run more than once
• Acknowledge, checkpoint, or commit work only after durable success, not before
• Avoid blocking or heavy work on latency-sensitive request or worker execution paths
• Shutdown, cancellation, and drain logic must let servers and workers exit cleanly without dropping or duplicating critical work silently
• Server shutdown should stop accepting new work, propagate cancellation, and drain listeners/workers with an explicit bounded timeout instead of relying on process exit
• Worker pools, channel-backed queues, and fan-out loops must use bounded concurrency with explicit backpressure or rejection behavior instead of silent drops or unbounded goroutine growth
• Cache fill, refresh, and invalidation logic must not create obvious thundering-herd or stale-data incidents
• Degradation and fallback behavior should fail gracefully and make partial availability explicit where clients or operators need to know
• Logging, metrics, and tracing should include enough contextual and trace/correlation identifiers to debug failures without leaking secrets or sensitive data, and should preserve wrapped error/cancellation causes where the logging stack supports it
• Long-running workers and consumers should emit enough progress/error context to distinguish poison messages, transient failures, and permanent contract/data issues
• Rate limiting, backpressure, and batch sizing should protect downstream systems and avoid retry amplification under load
• Readiness and health endpoints should not report success before required dependencies, caches, worker loops, or subscriptions are actually ready to serve traffic safely

Output Rules

• Report at most 7 findings.
• Include production failure scenario for each Major/Blocker.
• Include file:line evidence for each finding.
• Severity: Blocker | Major | Minor
• Confidence: High | Medium | Low
• Include a minimal, concrete fix.

Output Format

Every finding must use this exact bullet format for downstream tooling:

- [F-001] <Severity> | <Confidence> | <file:line> | <description>

Do NOT use markdown tables, numbered lists, or any other format for findings.