[Bug] Repository rename or transfer can stop webhook ingestion due to stale repo_full_name

[gazeatcode]

Description

The mirror keys tracked repositories by repos.repo_full_name and gates webhook ingestion by matching payload.repository.full_name to that row.

If a GitHub repository is renamed or transferred, webhook payloads begin carrying the new repository.full_name, while the mirror may still hold the old registered repo_full_name. In that state, normal repository-scoped events can be treated as unregistered and skipped, so ingestion silently stops for that repository.

Steps to Reproduce

1. Register and ingest a repository normally, for example owner-a/repo-x.
2. Rename or transfer the repository on GitHub so its full name changes, for example owner-b/repo-x.
3. Deliver later repository-scoped webhook events such as pull_request, issues, issue_comment, or pull_request_review.
4. Observe the mirror looks up payload.repository.full_name exactly in repos.
5. If only the old repo_full_name row is registered, observe the event is skipped as not registered.

Expected Behavior

Webhook ingestion should continue after repository rename or transfer without manual database repair. The mirror should use GitHub's stable repository ID to recognize that the new full name belongs to the already registered repository and keep repo-keyed mirror rows consistent.

Actual Behavior

Webhook routing is based on exact repo_full_name string lookup. After a rename or transfer, events with the new repository.full_name can miss the old registered row and be skipped.

Environment

• OS: Any
• Runtime/Node version: Node 20
• Browser (if applicable): N/A

Additional Context

Relevant paths:

• packages/db/01_repos.sql declares repo_full_name as the primary key.
• packages/das/src/webhook/webhook.service.ts reads payload.repository.full_name and gates ingestion by exact repo lookup.
• packages/das/src/webhook/handlers/installation.handler.ts creates and updates repository rows by current repo.full_name, with no stable-ID rename reconciliation.

This is consumer-visible because mirror data and scoring inputs can become stale for renamed or transferred repositories until an operator manually repairs the stored repository key.

[anderdc]

Not pursuing. The mechanism is real — webhook ingestion does silently stop after a rename — but for subnet-tracked repos this is a once-in-a-blue-moon event, and the recovery is a single SQL UPDATE per repo-keyed table. The maintenance cost of automatic reconciliation in the webhook hot path outweighs that. Closing.