feat(release-worker): assign sequence to new releases - #586
feat(release-worker): assign sequence to new releases#586alisawavezen12 wants to merge 3 commits into
Conversation
| const hasFiles = Array.isArray(payload.files) && payload.files.length > 0; | ||
|
|
||
| if (!validCommits && !hasFiles) { | ||
| return; |
There was a problem hiding this comment.
add debug log about release skipping with project id
| return; | ||
| } | ||
|
|
||
| await this.ensureRelease(projectId, payload.release); |
| * Ensure that a release gets one stable first-seen sequence. | ||
| * | ||
| * Release processing is intentionally sequential in the current deployment. |
There was a problem hiding this comment.
please, provide more clear explaination
| /** | ||
| * - insert new record with saved maps | ||
| * or | ||
| * - update previous record with adding new saved maps | ||
| */ |
| * or | ||
| * - update previous record with adding new saved maps | ||
| */ | ||
| if (!existedRelease) { |
There was a problem hiding this comment.
why this code has been removed?
There was a problem hiding this comment.
This code was moved to createReleaseIfMissing, which runs before saveSourceMap. So saveSourceMap only updates an existing release now.
| * Error code of MongoDB key duplication error | ||
| */ | ||
| /* eslint-disable @typescript-eslint/no-magic-numbers */ | ||
| const DB_DUPLICATE_KEY_ERROR = '11000'; |
There was a problem hiding this comment.
unexpected change. It was used to handle worker scaling.
| projection: { releaseSequence: 1 }, | ||
| }); | ||
|
|
||
| const releaseSequence = (lastRelease?.releaseSequence || 0) + 1; |
There was a problem hiding this comment.
I'm not sure it will work properly in case of several workers running in parallel.
why not to resolve it by date? |
2 participants
Summary
Add first-seen sequencing for newly registered releases in
release-worker.The sequence will be used by the upcoming release validator to determine the previous release of a project. This is required for comparing event groups between releases and identifying errors that likely stopped occurring after a release.
What changed
releaseSequencefield to new release documents.releasescollection.1independently for each project.(projectId, release)is first registered.releaseSequenceunchanged.Sequence assignment
The current release worker is configured to process messages sequentially:
Therefore, the next sequence is calculated from the maximum existing sequence for the project:
The sequence is stored on the release document and can later be used to find the previous release.
This PR intentionally does not add a separate counter collection. If the release worker is horizontally scaled or starts processing release messages concurrently in the future, sequence assignment must be revisited and protected with an atomic counter or another concurrency-safe mechanism.
Processing flow
Repeated uploads for the same release only update the existing document and do not create a new sequence.
Regular error events without a release continue through the normal event pipeline and do not create release documents.
Why
RabbitMQ delivery order cannot be used as the release timeline because messages may be delayed or redelivered. The stored sequence provides a stable first-registration order for new releases and will allow the future validator to compare a release with its predecessor.
Backward compatibility
releaseSequence.1for releases created after this change.Scope
This PR only prepares release ordering data. It does not include:
release-validatorworker;likelyFixedcalculation;