babysit_copr_build skips when DB shows success but status check may not be updated

[majamassarini]

Problem

The babysit_copr_build task skipped processing when it found the DB already showed success, but the GitHub status check for the SRPM build was never updated, leaving it stuck in "pending" state.

Observed Symptoms

Build ID: 10897621
PR: eclipse-bluechi/bluechi#1127
Issue: SRPM build status check remained pending on GitHub despite successful build

Evidence from Logs

The babysit task shows a race condition:

[2026-08-24 15:23:20,893] task.babysit_copr_build[...] The status of 10897621 is 'running'.
[2026-08-24 15:23:21,038] task.babysit_copr_build[...] Task retry: Retry in 60s: 
    PackitCoprBuildTimeoutException('No feedback for copr build id=10897621 yet')

[2026-08-24 15:24:21,088] task.babysit_copr_build[...] The status of 10897621 is 'succeeded'.
[2026-08-24 15:24:21,090] task.babysit_copr_build[...] DB state of 10897621 says 
    <BuildStatus.success: 'success'>, things were taken care of already, skipping.

What happened:

1. At 15:23:20 - Copr API says build is "running", babysit retries in 60s
2. Between 15:23:21 and 15:24:21 - Something else updated the DB to "success"
3. At 15:24:21 - Babysit finds DB already shows success and skips with "things were taken care of already"

Result: Status check was never updated

What Updated the DB?

Between the two babysit runs, three copr_build_end tasks executed for the individual chroots:

[15:23:56] TaskName.copr_build_end[873692d4...] fedora-rawhide-x86_64
[15:24:09] TaskName.copr_build_end[d9ca6964...] fedora-rawhide-aarch64  
[15:24:17] TaskName.copr_build_end[1aa436fa...] epel-10-x86_64

These tasks successfully:

• Updated their respective RPM build targets in the DB
• Set status checks for their chroots (e.g., rpm-build:fedora-rawhide-x86_64)

Hypothesis: One of these tasks likely also updated the SRPM build row in the DB to "success" (perhaps as a side effect), but did not update the SRPM build's GitHub status check.

However, we cannot confirm from the logs alone:

• Which task updated the SRPM build DB row
• Why the SRPM status check was not updated at that time
• Whether this was expected behavior or a separate bug

The Code

In packit_service/worker/helpers/build/babysit.py lines 326-331:

if build.status not in (BuildStatus.pending, BuildStatus.waiting_for_srpm):
    logger.info(
        f"DB state of {build_id} says {build.status!r}, "
        "things were taken care of already, skipping.",
    )
    continue

When the babysit task finds the DB already shows a non-pending status, it assumes "things were taken care of already" and skips all further processing - without verifying that the GitHub status check was actually updated.

Questions

1. Who should update the SRPM status check?

   • Should it be the copr_build_end handlers?
   • Or should babysit be the fallback that ensures it gets set?

2. Should babysit verify the status check before skipping?

   • Currently it trusts that if DB is updated, the status check was too
   • But this assumption appears to be incorrect

3. Is there a legitimate scenario where:

   • The DB gets updated to success
   • But the status check should intentionally not be set?

Impact

User-visible: PR status checks stuck in "pending" state even though the build completed successfully.

This appears to happen when:

• A handler successfully updates the DB
• But fails to update (or is not responsible for updating) the GitHub status check
• And the babysit task runs after the DB is already updated

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 7:38 AM UTC · Completed 7:43 AM UTC

Commit: ca574c7 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $1.04

[fullsend-ai-triage]

Triage Summary

Severity: Medium · Category: Bug

The race condition is well-identified. The core issue is that update_copr_builds() and update_srpm_build_state() both use DB status as a proxy for "status check was sent" — but the copr_build_end handlers for individual chroots can update the SRPM build's DB row without updating its GitHub status check.

Related Issues

• Copr SRPM build can end up failed despite Copr sending build.end event with success #3138 covers a different Copr/SRPM scenario (import failure after success event) but shares the theme of SRPM status check reliability

Recommended Fix

The guard in update_copr_builds() (the build.status not in (pending, waiting_for_srpm) check) should be relaxed to still dispatch a status check update when the Copr API confirms the build succeeded, even if the DB already reflects that. An idempotent status check update is safe and prevents the race from leaving checks stuck. The same principle applies to update_srpm_build_state()'s srpm_build.status == BuildStatus.pending guard.

Proposed Test Case

def test_babysit_updates_srpm_status_check_even_when_db_already_success():
    """
    When copr_build_end handlers update the SRPM build DB row to
    success before babysit runs, babysit should still trigger the
    SRPM status check update rather than skipping.
    """
    # Setup: SRPM build with status=success in DB (already updated by
    # copr_build_end handler), but GitHub status check not yet sent.
    # Mock Copr API to return succeeded build.
    # Call check_copr_build(build_id)
    # Assert: CoprBuildEndHandler was invoked for the SRPM chroot,
    # or equivalent status-check-setting logic was triggered.
    # Assert: The function did NOT skip with "things were taken care of"
    # without verifying the status check.

---

Labels: Bug involving Copr babysit race condition affecting GitHub status check reporting; area/copr already applied, adding kind/bug and area/github.

---

Next steps:

• /fs-code — agent creates a PR to implement this issue
• /fs-code <your instruction> — agent implements with your specific guidance

[fullsend-ai-coder]

🤖 Finished Code · ✅ Success · Started 7:44 AM UTC · Completed 7:56 AM UTC

Commit: ca574c7 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $4.40