Conversation
chore: release 1.2.1
CI said what the old assertion could not: "a second job was accepted while 01M21AB... held the lock. That job is now running at 0%." The first job was alive, so this was never the race it looked like -- the second launcher was accepted because there was no lock to see yet. `createJob` writes `state: 'running'` in the LAUNCHER, before the child exists, and the child is what calls `withJobLock`. Between the launcher exiting and the child taking the lock there is a window with no lock file, which is exactly why `jobLockHolder` documents itself as advisory and why `exclusiveLock.ts` says the parent gives a synchronous refusal while the child takes the real lock. The test polled the state and then demanded a refusal -- a guarantee the design never made. It now waits for the lock file itself, which is the only state where an up-front refusal is meant to hold. The product behaviour is unchanged and still as documented: two `--detach` launches inside that window are both accepted, and the second job then fails against the real lock.
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.
Automated back-merge of
mainintodevelop. Auto-merge is on, so this merges itself once the required checks pass.Latest commit on main:
5bd7eef- Merge pull request #9 from lorem-dev/developTriggered by push to
mainin workflowBack-merge main -> developrun34272971888.Merge this with a MERGE COMMIT, not a squash. A squash copies main's content without its history, so git stops knowing that develop already contains it and every later back-merge conflicts on files nobody touched. That is what happened once already; see the comment at the top of
.github/workflows/backmerge.yml.