GeezerVison

devin-ai-integration Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

devin-ai-integration Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

Two definitions of the same queue that differ only in combinedConcurrencyLimit
now warn and keep the first definition instead of letting registration order
pick the deployed cap.

A bare string home (alone or as a tuple's first element) no longer registers
queue metadata, so module evaluation order can no longer shadow a declared
queue's limits with an empty definition.

Both gate parsers now drop gates with empty or over-length queue names,
drop gates whose literal key exceeds the manifest cap, and treat an
empty-string key as omitted so it inherits the run's key instead of
pinning an empty pool.

The webapp and the enqueue system carried identical copies of the gate
contract with nothing enforcing their parity. parseGates now lives in
the run-engine package with unit tests covering every rule (bounds kept
inclusive at 128, empty keys inherit, malformed entries dropped, capped
at two), and both callers delegate to it.

Tasks declare concurrency directly: an inline { perKey, total } shape
caps the task, and concurrencyLimit() declares a named, shareable limit
that tasks hold via the same option (at most one inline plus two named).
Trigger calls switch a run's named limits with their own concurrency
option, strings only like queue. The queue tuple syntax and
combinedConcurrencyLimit never ship: queue() is a line again, its
concurrencyLimit deprecated in place, and the manifest carries the new
declarations for the server to compile.

Removes the combined override client methods the previous commit
intended to drop, moves react-hooks trigger options off the queue tuple
onto the concurrency names, merges a duplicated type import, and marks
the new type-only imports as such for the linter.

Passing undefined for a gateless original fell back to the task's
current gates, so old runs replayed after new limits were added would
silently gain them.

The index workers emit them into WorkerManifest, which is a separate
schema from the deploy metadata and also needs the field.

…iscarding

The option was silently dropped by the seven single-task and
subscribe/wait paths and doubled at four by-id batch sites. A named
limit object written inline in a task's concurrency now registers as a
declaration instead of losing its caps, and trigger-time limit names
must be non-empty strings.

Names are 1-122 characters of letters, numbers, underscores and
hyphens, checked by the factory, task declarations and trigger
options alike, so distinct names always stay distinct after queue
name sanitization.

…d limits

The end-to-end gate capacity is three (the anonymous inline-limit gate
plus two named limits), so trigger-time replacement can no longer lose
a named limit to a downstream cap. Limit shapes also start at 1: block
everything is a pause or an override, not a declared limit, so a stored
zero always reads as no limit.

Gate capacity is four end to end (three requested gates plus the
task's anonymous inline-limit gate), so replaying a three-gate run
against a task that later gained an inline limit resolves to four and
still enqueues. A run stored without gates now replays with the task's
currently declared limits instead of a fabricated empty array that
silently cleared them, matching how replays adopt the current queue
and retry config.

devin-ai-integration Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

Manage named concurrency limits at runtime: list and retrieve report
each limit's bounds plus its live running and queued counts, override
changes only the given bounds (total zero pauses the limit), and reset
restores the declared values.

…ting

Matches the SDK's trigger validation, and the shared changeset now
versions react-hooks alongside sdk and core.

…ntry type requires

The index step collected concurrencyLimits into the worker manifest, but both
the dev session and the deploy index controller dropped the field when building
the create-background-worker request, so declared named limits registered with
no bounds and were never enforced.