feat(scans): allow one in-flight scan per branch, not per project - #9
Merged
Conversation
ix_scans_project_active serialized every scan of a project, so pushing to main and release/1.x at once made one CI job wait on the other's scan or take a 409 it could do nothing about. The branches write disjoint snapshots; nothing about the data required that. Migration 0047 rebuilds the index on (project_id, ref) NULLS NOT DISTINCT. Without NULLS NOT DISTINCT the ref-less ad-hoc scans that make up most rows would stop colliding entirely, turning the guard into nothing for the common case; with it they keep exactly today's behaviour. The Scan button now greys out only while another ad-hoc scan is in flight, since that is the only kind it can conflict with. That needed ref on the overview's recent-scans summary.
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
1 participant
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.
ix_scans_project_activeenforced at most one queued/running scan per project. Once branches became a first-class axis (#6, #7, #8), that stopped matching the model: pushing tomainandrelease/1.xat the same time made one CI job wait on the other's scan, or take a409it could do nothing about. The two branches write disjoint snapshots, so nothing about the data required serializing them.Migration 0047 rebuilds the index on
(project_id, ref)withNULLS NOT DISTINCT. That second half is the point:refis NULL for ad-hoc scans, which is most rows, and under the default NULLS DISTINCT a plain(project_id, ref)unique index would stop constraining them at all — every manual re-trigger would queue another scan and the stability guard would become nothing for the common case. WithNULLS NOT DISTINCT(PostgreSQL 15+; we pin 17) all ref-less rows of a project still collide, so ad-hoc behaviour is unchanged and only named branches gain concurrency.The
409detail now names the busy branch, since "a scan is already running for this project" would send a caller looking for a conflict on a branch they never touched.The Scan button was greying out on any active scan, which would have hidden the whole change in the UI. It triggers an ad-hoc run, so only another ad-hoc scan can conflict with it — it now gates on that, and the in-progress chip stays visible either way. This needed
refon the overview's recent-scans summary.The per-team concurrency cap docstring claimed the old index guaranteed "at most ONE active scan per project"; corrected. The bound it derives comes from the per-user rate limit and is unchanged.