Copilot Chat Cookbook Deep Dive: Debug Errors

Dhanoop Bhaskar June 29, 2026 copilot

Why this category matters

Debugging prompts are most useful when they include concrete failure context: error text, logs, and relevant files.

The Debug errors category demonstrates this pattern with three practical examples.

Use cases

  • Developers debugging production-like failures under time pressure
  • QA and CI owners diagnosing flaky test behavior
  • Developers learning to write high-signal debugging prompts

The 3 examples in this category

  1. Debugging invalid JSON
  2. Handling API rate limits
  3. Diagnosing test failures

Diagram: Debug prompt-to-fix loop

+----------------------------+
| Capture failure evidence   |
| - error message            |
| - logs                     |
| - relevant code/files      |
+----------------------------+
             |
             v
+----------------------------+
| Prompt Copilot Chat        |
| - ask root cause           |
| - ask targeted fix         |
+----------------------------+
             |
             v
+----------------------------+
| Validate fix               |
| - rerun tests              |
| - reproduce scenario       |
| - check regressions        |
+----------------------------+

1) Debugging invalid JSON

Scenario from the cookbook:

  • A JSON parse error occurs due to malformed JSON.
  • Prompt asks why JSON is invalid and how to fix it.

Prompt pattern:

Why is my JSON object invalid and how can I fix it?

Expected response style:

  • Pinpoint exact syntax issue.
  • Return corrected JSON.

Validation checklist:

  • Parse with a JSON parser.
  • Confirm no trailing commas or quote mismatches.
  • Ensure original semantics remain unchanged.

2) Handling API rate limits

Scenario from the cookbook:

  • API calls can fail due to limits; app needs resilient retry behavior.

Prompt pattern:

How can I handle API rate limits within get_weather().

Typical improvement pattern in response:

  • Retry session
  • Backoff strategy
  • Error handling around request failures

Validation checklist:

  • Confirm backoff and retry limits match service policy.
  • Handle HTTP status families intentionally.
  • Ensure failures return predictable API responses.

3) Diagnosing test failures

Cookbook showcases two high-value scenarios:

  • Passes locally, fails in CI (timezone/time-boundary mismatch).
  • Intermittent failures (race condition in async/background workflow).

Prompt pattern with strong context:

Please take a look at this CI failure message.
The test passes locally, but intermittently fails in CI.
Can you help me figure out if this looks like a code bug,
environment issue, or a flaky test?

<failure excerpt>
#file:order.py
#file:test_order_service.py

Why this works:

  • Includes failure output.
  • Includes relevant files.
  • Asks for classification and root-cause reasoning.

Validation checklist:

  • Reproduce with deterministic clocks/timezones where relevant.
  • Add synchronization/waiting for async state transitions.
  • Rerun tests multiple times in CI-like conditions.

Debug prompting patterns that consistently help

  • Ask for root-cause categories, not only fixes.
  • Include before/after logs for flaky behavior.
  • Ask for minimal patch plus explanation.
  • Ask for follow-up tests that prevent recurrence.

Worked example

Scenario

A test passes locally but fails intermittently in CI around date boundaries.

Code under test

# order.py
from datetime import date, timedelta

def expected_delivery_date(order_date: date) -> date:
    """Returns next business day. Skips Friday-into-weekend."""
    if order_date.weekday() >= 4:  # Friday=4, Saturday=5, Sunday=6
        days_ahead = 7 - order_date.weekday()
    else:
        days_ahead = 1
    return order_date + timedelta(days=days_ahead)

# test_order_service.py
from datetime import date
from order import expected_delivery_date

def test_weekday_delivery():
    today = date.today()          # Bug: binds test to system clock
    result = expected_delivery_date(today)
    assert result > today         # Passes Monday–Thursday, fails Friday in some timezones

The test uses date.today(), which means its assertions change depending on when and where it runs. In CI, the server timezone or date boundary can push the evaluation to Friday, causing the test to fail.

Evidence bundle to include

  • Failure excerpt
  • Runtime timezone details
  • Relevant implementation and test files

Prompt

Classify this failure as code bug, environment issue, or flaky test.
Then provide:
1) likely root cause,
2) minimal patch,
3) regression test additions,
4) rerun strategy.

Failure log:
<paste CI failure>

Files:
#file:order.py
#file:test_order_service.py

Expected good response characteristics

  • Explains why timezone assumptions cause divergence.
  • Proposes deterministic clock/timezone handling.
  • Adds regression coverage for edge boundaries.

Validation steps

  1. Re-run failing tests multiple times with controlled timezone.
  2. Re-run entire suite in CI.
  3. Confirm no unrelated behavior changed.

Key takeaways

  • Best debugging prompts include concrete evidence, not vague symptoms.
  • Root-cause classification is often more valuable than immediate patching.
  • Flaky test diagnosis benefits heavily from logs and file references.
  • Every suggested fix must be validated with reruns and regression checks.


References

Post a Comment

0 Comments