fix(database)!: use transactions tied to repo counters for hook and build to avoid collisions #1353
Conversation
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
Codecov Report❌ Patch coverage is
❌ Your project check has failed because the head coverage (58.36%) is below the target coverage (90.00%). You can increase the head coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #1353 +/- ##
==========================================
+ Coverage 58.16% 58.36% +0.20%
==========================================
Files 646 645 -1
Lines 24931 24864 -67
==========================================
+ Hits 14500 14511 +11
+ Misses 9767 9681 -86
- Partials 664 672 +8
🚀 New features to boost your workflow:
|
ecrupper
changed the title
KellyMerrick
previously approved these changes
Nov 21, 2025
wass3rw3rk
reviewed
Dec 30, 2025
| modReq := &ModifyRequest{ | ||
| Pipeline: string(data), | ||
| Build: apiBuild.GetNumber(), | ||
| Build: repo.GetCounter() + 1, // this is an assumption |
Member
There was a problem hiding this comment.
does this introduce concurrency issues?
Contributor
Author
There was a problem hiding this comment.
Depends on what the modification endpoint does. I wasn't sure whether to remove the build number completely or make an assumption
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.
I hesitate to say "fixes" for go-vela/community#997 and go-vela/community#213 because at very very high concurrency (300 simultaneous webhooks for one repo), it's still possible to see this issue I noticed. However, these changes can handle a great deal more concurrency compared to
main.In my testing, I was able to send 30+ webhooks simultaneously and 300+ with a .25 second delay and not run into duplicate key issues.
The key difference here is removing fetches for counters and instead tying the repo counters to the create functions for hooks and builds.
This PR also forces the worker's substitution routine to play a critical role in rendering any env vars containing the build number. This breaks situations in templates when teams use those specific Vela platform vars in a sprig func like
{{ vela "BUILD_NUMBER" }}This should really just be
${VELA_BUILD_NUMBER}, but if a user is — for whatever reason — performing some sort of inline Go logic based on build number, this would be a regression for them.