Skip to content

fix: affected-alert remediation (private fork) never produces a fork — doesn't remediate #133

Description

@toufali

Problem

The affected-alert path (create advisory → private fork → clone → Claude-fix in the fork) doesn't work. create_advisory_and_fork frequently returns an empty fork name (the polling loop never finds the private fork), so the clone step got https://github.com/.git/ and hard-failed. That failure was the source of the re-investigation loop on mozilla/fxa.

The loop itself is now mitigated (#129/#130 tag on failure; empty fork routes to advisory_only), but affected alerts still get zero remediation — the path just fails cleanly instead of looping.

Root question

Why is the private fork empty? Candidates: advisory fork creation is async and the poll window/field path is wrong, or a permissions gap on repository-advisories.

Proposal

Two options:

  1. Fix fork detection/polling so the private-fork flow actually completes.
  2. Simpler + more robust: for affected alerts, open a normal bump PR on the main repo (same mechanism as transitive bumps) and only use the private-fork + Claude-fix flow when the fix genuinely needs code changes beyond a version bump. Most 'affected' transitive advisories are still resolved by bumping the dependency, so the fork dance is overkill for them.

Impact

Enables real remediation of affected alerts (currently none).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions