fix: enqueue PR files refresh on base-branch edits#64
Open
jakearmstrong59 wants to merge 1 commit into
Open
Conversation
6fdaea7 to
897c2ac
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
pull_requestwebhook handler enqueues aPR_FILESjob onopened,synchronize, and mergedclosed, but not onedited. When a maintainer retargets a PR's base branch, GitHub firespull_request.editedwithchanges.basepopulated and a newpr.base.sha. Today the handler writes the newbaseShaonto the PR row but leavespr_files,pr_file_contents, andmerge_base_shapinned to the previous base — andscoring_data_storedstaystrue, falsely advertising the bundle as current.This change detects base retargets on
pull_request.edited(viapayload.changes?.base), clearsscoring_data_stored, and enqueues the samePR_FILESjob the synchronize path uses. The job's deterministicprFilesJobId(repo, pr, headSha, baseSha)naturally dedupes against any in-flight fetch for the new generation, andfetchAndStorePrFilesalreadyrecomputes the merge-base and re-upserts file content on every run, so no fetcher changes are required.
Title/body edits are untouched — they don't set
changes.base, so they keep running only the existingPR_METADATAjob.Related Issues
Fixes #62
Type of Change
Testing
Verified via live webhook against a test repo:
main; wait forpr_files/pr_file_contentsto populate andscoring_data_storedto flip totrue.PR_FILESjob enqueued for the new(headSha, newBaseSha)generation;scoring_data_storedmomentarilyfalse, thentrueonce the new fetch completes.merge_base_shais recomputed andpr_file_contents.base_contentreflects blobs from the new base branch.PR_FILESjob is enqueued (onlyPR_METADATA).Also ran
npm run format:check,npm run lint, andnpm run buildinpackages/das/— all pass.Checklist
76fd0a8)