{{ message }}
Repository navigation
fix(server): align worker_concurrency fallbacks with migration 0011 default of 64 - #871
Merged
WaylandYang merged 2 commits intoSep 23, 2026
Conversation
… default of 64 Migration 0011 raised `deployment_settings.worker_concurrency`'s default from 32 to 64 (and the CHECK from BETWEEN 1 AND 32 to BETWEEN 1 AND 256) because the previous default was lower than the per-model limits summed, so a 219-document extraction batch starved the queue. The SQL side was fixed; two Rust fallbacks were left at 32. `access::worker_concurrency` already returns 64 on missing row, and `the_backstop_can_be_raised` guards against that drift. Two server-side fallbacks bypassed that test: - `crates/utopia-server/src/main.rs:173` — `.unwrap_or(32)` on the Result from access::worker_concurrency. This is hit when the SQL function itself errors (DB unreachable, query timeout) — exactly the scenario where the system is already degraded. Running with 32 in that window is the same starvation 0011 was designed to prevent. - `crates/utopia-server/src/state.rs:64` — the initial AtomicUsize value before main.rs's `.store(...)` runs. Mostly benign (no request can land in the gap) but wrong as written, and silently regressed by the same migration. Both bumped to 64 with a comment pointing at the column default and the access::worker_concurrency fallback, so the next person who changes one side sees the other two. Not touching set_worker_concurrency (1..=256 validator) — that one was already correct. Signed-off-by: rollroyces <royce@rollroyces.com>
WaylandYang
approved these changes
Sep 23, 2026
WaylandYang
left a comment
WaylandYang
left a comment
Contributor
There was a problem hiding this comment.
Verified against dev: migration 0011 sets the column default to 64
(ALTER COLUMN worker_concurrency SET DEFAULT 64), access::worker_concurrency
falls back to 64 on a missing row, and the two server-side sites were still 32
(main.rs:175 on the Result, state.rs:64 for the pre-load value).
the_backstop_can_be_raised still exists under tests/store/ after the test
consolidation and covers the store side only, so these two really were outside it.
The comments say why each site is what it is and point at the other two, which is
the thing that stops the next drift. LGTM.
Merged
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
2 participants
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.
Align server-side worker_concurrency fallbacks with migration 0011's default (64)
Migration 0011 raised
deployment_settings.worker_concurrency's default from 32 to 64 (and the CHECK fromBETWEEN 1 AND 32toBETWEEN 1 AND 256) because the previous default was lower than the per-model limits summed, so a 219-document extraction batch starved the queue. The SQL side was fixed; two Rust fallbacks were left at 32.access::worker_concurrencyalready returns 64 on missing row, andthe_backstop_can_be_raised(crates/utopia-store/tests/the_backstop_can_be_raised.rs) guards against drift there. Two server-side fallbacks bypassed that test:crates/utopia-server/src/main.rs:173—.unwrap_or(32)on theResultfromaccess::worker_concurrency. Hit when the SQL function itself errors (DB unreachable, query timeout) — exactly the scenario where the system is already degraded. Running with 32 in that window is the same starvation 0011 was designed to prevent.crates/utopia-server/src/state.rs:64— the initialAtomicUsizevalue beforemain.rs's.store(...)runs. Mostly benign (no request can land in the gap) but wrong as written and silently regressed by the same migration.Both bumped to 64 with a comment pointing at the column default and the
access::worker_concurrencyfallback, so the next person who changes one side sees the other two.Not touching
set_worker_concurrency's validator (1..=256) — that one was already correct.The drift shape is the same as the bug
the_backstop_can_be_raisedwas written to catch: a number defined in two places (one SQL, one Rust) that drifted out of sync. Adding a server-side drift test would require theutopia-storetest crate to depend onutopia-server, which violates layering — so the guard for now is the comment pointing at the column default, and the existing test continues to guard theaccess::worker_concurrencyfallback.If we ever see this drift happen again, the right fix is to hoist
64into a singlepub const WORKER_CONCURRENCY_DEFAULTinutopia-store/src/access.rsand have the server side reference it. Worth doing if a third place grows the constant.Signed-off-by: rollroyces royce@rollroyces.com