Skip to content

Update Nix flake - #1

Open
github-actions[bot] wants to merge 1 commit into
mainfrom
update_flake_lock_action
Open

Update Nix flake#1
github-actions[bot] wants to merge 1 commit into
mainfrom
update_flake_lock_action

Conversation

@github-actions

@github-actions github-actions Bot commented Mar 15, 2026

Copy link
Copy Markdown

Automated changes by the update-flake-lock GitHub Action.

Flake lock file updates:

• Updated input 'nixpkgs':
    'github:nixos/nixpkgs/aca4d95' (2026-03-06)
  → 'github:nixos/nixpkgs/0bb7ec5' (2026-07-08)

Running GitHub Actions on this PR

GitHub Actions will not run workflows on pull requests which are opened by a GitHub Action.

To run GitHub Actions workflows on this PR, close and re-open this pull request.

@github-actions
github-actions Bot force-pushed the update_flake_lock_action branch from eff7ba6 to aca4897 Compare March 22, 2026 01:49
@github-actions
github-actions Bot force-pushed the update_flake_lock_action branch from aca4897 to 5680eb5 Compare March 29, 2026 01:57
@github-actions
github-actions Bot force-pushed the update_flake_lock_action branch from 5680eb5 to c013faf Compare April 5, 2026 01:59
@github-actions
github-actions Bot force-pushed the update_flake_lock_action branch from c013faf to a19f885 Compare April 12, 2026 02:03
@github-actions
github-actions Bot force-pushed the update_flake_lock_action branch from a19f885 to 1616173 Compare April 19, 2026 02:07
@github-actions
github-actions Bot force-pushed the update_flake_lock_action branch from 1616173 to 35e0743 Compare April 26, 2026 02:10
@github-actions
github-actions Bot force-pushed the update_flake_lock_action branch from 35e0743 to 57006e9 Compare May 3, 2026 02:26
@github-actions
github-actions Bot force-pushed the update_flake_lock_action branch from 57006e9 to 033503c Compare May 10, 2026 02:29
@github-actions
github-actions Bot force-pushed the update_flake_lock_action branch from 033503c to f836ea4 Compare May 17, 2026 02:36
@github-actions
github-actions Bot force-pushed the update_flake_lock_action branch from f836ea4 to ef60723 Compare May 24, 2026 02:44
@github-actions
github-actions Bot force-pushed the update_flake_lock_action branch from ef60723 to 325cbaa Compare May 31, 2026 02:53
@github-actions
github-actions Bot force-pushed the update_flake_lock_action branch from 325cbaa to 06b5bac Compare June 7, 2026 02:57
@github-actions
github-actions Bot force-pushed the update_flake_lock_action branch from 06b5bac to 3253bfa Compare June 14, 2026 03:27
@github-actions
github-actions Bot force-pushed the update_flake_lock_action branch 2 times, most recently from a5193c2 to 5ad9ce6 Compare June 28, 2026 02:54
@github-actions
github-actions Bot force-pushed the update_flake_lock_action branch from 5ad9ce6 to de1c0c7 Compare July 5, 2026 02:34
Flake lock file updates:

• Updated input 'nixpkgs':
    'github:nixos/nixpkgs/aca4d95' (2026-03-06)
  → 'github:nixos/nixpkgs/0bb7ec5' (2026-07-08)
@github-actions
github-actions Bot force-pushed the update_flake_lock_action branch from de1c0c7 to 48eaef8 Compare July 12, 2026 02:09
Powermacintosh pushed a commit that referenced this pull request Jul 14, 2026
…o-gitea#38200)

## Summary

Fixes two related bugs that cause jobs in large workflows (50+ parallel
jobs) to never get a runner assigned even though runners are free.

### Bug 1 — Concurrent runner race

When N runners all poll `FetchTask` with a stale `tasksVersion`
simultaneously, they all query the same waiting job list sorted by
`(updated, id)` and all pick **job #1**. Only one wins the `UPDATE WHERE
task_id=0` optimistic lock; the rest return empty-handed but still
receive `latestVersion` in the response. They then consider themselves
"up to date" and skip `PickTask` on every subsequent poll, leaving jobs
go-gitea#2–50 permanently unassigned.

**Fix:** `CreateTaskForRunner` now iterates through all matching waiting
jobs. When the optimistic lock fails on job #1, it immediately tries job
go-gitea#2, then go-gitea#3, etc., each in its own independent transaction so a failed
attempt rolls back cleanly before the next candidate is tried.
`PickTask` no longer wraps this call in an outer `db.WithTx` (which
caused `halfCommitter` entanglement that prevented per-attempt
rollbacks).

### Bug 2 — Idle runner doesn't re-check after finishing a task

`tasks_version` only bumps when a job transitions **to** waiting (new
workflow triggered, blocked→unblocked). After a runner finishes its
current task it polls `FetchTask` with `tasksVersion == latestVersion`,
so the server skips `PickTask` entirely — the remaining 45 waiting jobs
are invisible to the now-idle runner.

**Fix:** Also call `IncreaseTaskVersion` in `UpdateRunJob` when a
(non-reusable-caller) job transitions to a **done** state. Idle runners
then see a version mismatch on their next poll and attempt `PickTask`,
picking up the remaining jobs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants