Opens in a new tab
AIOps SRE
Search

Learning path · 5 steps

Take an unsafe retry through a complete PR review

Build a small reviewable change around the starter’s duplicate-ticket bug. You will create the base and proposed revision, ask a focused review question, reproduce the concern locally and leave a corrected PR with a traceable test. The value is the connection between finding and behavior, even if the automated reviewer misses the issue.

Ready guideDocumentation checked
In this guide 6 sections

These walkthroughs use the downloadable synthetic support-service project. Work in a disposable copy so you can compare the proposed changes with the original defects. Each tool needs separate authorized access; the starter includes no production credentials or incident data.

What you will build

A PR whose retry behavior a reviewer can verify

The finished artifact is a small PR: a clear description of the ambiguous-write case, a regression test, the checked correction and a short response to the review. Use a disposable repository you are permitted to share with CodeRabbit.

Included example files

A small support-service project

Synthetic code, logs, a deliberately stale runbook, and six support tickets. The JavaScript uses Node.js 22+ with no packages or network calls. Product accounts and model access are separate.

  • retry.mjs
  • retry.test.mjs
  • checks/retry-contract.test.mjs
Download starter ZIP

  1. Create the safe base

    Use the single-send implementation shown in the CodeRabbit tool walkthrough as the repository’s base, together with retry.test.mjs. Check that the successful-call test passes. Connect only a repository you are authorized to share with the review service.

    Terminal command
    node --test retry.test.mjs

    Check before continuingThe base calls send once and contains no catch-and-retry branch.

    Open the tool guide

  2. Propose the retry change

    On a separate branch, replace the safe base with the starter’s deliberately unsafe retry.mjs. Open a small PR describing the intended recovery and the risk of a lost response after ticket creation. Keeping the unsafe retry in the diff makes the review target unambiguous.

    Check before continuingThe PR diff introduces the second send; it is not hidden in the unchanged base.

    Open the tool guide

  3. Ask about a reachable failure

    Read any automatic review, then ask the question below in a PR comment if needed. The prompt names the missing guarantee instead of asking for a generic code-quality score.

    Request to adapt
    @coderabbitai The service may create a ticket and then lose its response. Trace what this new retry does in that case. Show where a second write can happen and suggest a test that observes it. Do not assume server-side idempotency.

    Check before continuingA useful finding describes the first side effect, rejected response and repeated send. A missing finding is also a result to record.

    Open the tool guide

  4. Reproduce before fixing

    Run the supplied retry contract locally on the proposed revision. The synthetic send records a write before throwing. Read its failure rather than relying on the reviewer’s severity label, then add a focused regression test to the PR.

    Terminal command
    node --test checks/retry-contract.test.mjs

    Check before continuingThe unsafe revision fails the contract without making a network call or creating a real ticket.

  5. Close the review with evidence

    Restore a justified single-send behavior, run both checks and inspect the updated diff. Reply with the test and revision that address the concern. Keep human approval and branch protections, and record any review suggestions that you had to rule out.

    Terminal command
    node --test retry.test.mjs checks/retry-contract.test.mjs

    Check before continuingBoth checks pass on the revised branch, and the review points to the actual regression test.

    Open the tool guide

Check the finished project

Verify your project
node --test retry.test.mjs checks/retry-contract.test.mjs

The corrected revision passes both checks and attempts the write once. The review discussion should identify the original path, explain the fix and state that safe retrying would require additional guarantees. No number of review comments substitutes for those checks.

Tool guides for this path

CodeRabbitCode review

An authored walkthrough using the synthetic starter project and linked official tool documentation. Baseline fixture behavior and the local evaluator were checked. The assistants, review service and model calls were not run for this path.

Browse all learning paths