Skip to content

chore: move dependents onto client 0.3 and queue 0.24 - #98

Merged
loks0n merged 2 commits into
mainfrom
feat/pools-2-dependents
Jul 31, 2026
Merged

chore: move dependents onto client 0.3 and queue 0.24#98
loks0n merged 2 commits into
mainfrom
feat/pools-2-dependents

Conversation

@loks0n

@loks0n loks0n commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

Follow-up to #94 / pools 2.0.0.

pools 2.0.0 changed how a pool is constructed, and both Utopia\Client\Pool and Utopia\Queue\Broker\Pool take one, so the bump shipped as client/0.3.0 and queue/0.24.0 (both released). Every consumer in the monorepo was pinned below those, which left messaging unbuildable from the registry — it requires pools ^2.0 and client ^0.2, and no released 0.2.x allows pools 2:

- Root composer.json requires utopia-php/client ^0.2 -> satisfiable by utopia-php/client[0.2.0, ..., 0.2.3].
- utopia-php/client[0.2.0, ..., 0.2.3] require utopia-php/pools ^1.0 -> found utopia-php/pools[1.0.0, ..., 1.1.1]
  but it conflicts with your root composer.json require (^2.0).
package dependency before after
messaging client ^0.2 ^0.3
fastly client ^0.1.1 || ^0.2 ^0.1.1 || ^0.2 || ^0.3
storage client 0.2.* 0.2.* || 0.3.*
platform queue ^0.22 ^0.23 || ^0.24

messaging moves outright, since its pools ^2.0 requirement rules out the 0.2 line anyway. The rest widen: none of them touches pools directly, both majors work for them, and pinning would force their consumers to upgrade in lockstep.

platform was two majors behind — it could not even see queue/0.23.0, the fix that keeps a consumer alive when the broker fails. That one matters here specifically: pools 1.x reconnect delays were the accidental backoff standing in for the missing guard, so a platform pinned to ^0.22 turns a broker outage into a crash loop the moment it picks up pools 2. It constructs Swoole($consumer, $workersNum, $queueName) and Server($adapter), neither of which changed across 0.23 or 0.24.

No source changes: the call-site migration for client, messaging and queue already shipped in #94.

Verification

Registry-resolved against the published pools/2.0.0, client/0.3.0 and queue/0.24.0 — messaging 19 tests, storage 27, platform 9, fastly 4, all green. bin/monorepo validate and check clean for all four.

Releases

  • pools/2.0.0
  • client/0.3.0
  • queue/0.24.0
  • messaging — needs a release after this merges; its constraint is what unblocks it
  • fastly, storage, platform — patch releases whenever convenient, the widenings are non-breaking

🤖 Generated with Claude Code

pools 2.0.0 changed how a pool is constructed, and client's Pool takes
one, so client shipped that bump as 0.3.0. Every client consumer in the
monorepo pinned inside 0.2, which left messaging unbuildable from the
registry: it requires pools ^2.0 and client ^0.2, and no released 0.2.x
allows pools 2.

messaging moves to ^0.3 outright, since its pools ^2.0 requirement rules
out the 0.2 line anyway. fastly and storage widen rather than move — they
never touch pools, so both client majors work for them and pinning would
force their consumers to upgrade in lockstep.

Verified registry-resolved against the published client/0.3.0 and
pools/2.0.0: messaging 19 tests, storage 27, fastly 4, all green.
platform still required queue ^0.22, so it could not see queue/0.23.0 —
the fix that keeps a consumer alive when the broker fails. That fix
matters here specifically because pools 1.x reconnect delays were the
accidental backoff standing in for the missing guard, so a platform
pinned to 0.22 turns a broker outage into a crash loop the moment it
picks up pools 2. queue/0.24.0 carries the pools ^2.0 bump.

Both majors are allowed rather than just the newest: platform constructs
Swoole($consumer, $workersNum, $queueName) and Server($adapter), neither
of which changed across 0.23 or 0.24, and platform never touches the
pooled broker, so nothing forces its consumers to move in lockstep.

Verified registry-resolved against queue/0.24.0 (pools 2.0.0
transitively): 9 tests green, check and validate clean.
@loks0n
loks0n requested a review from lohanidamodar as a code owner July 31, 2026 09:10
@loks0n loks0n changed the title chore: allow client 0.3 in fastly, messaging and storage chore: move dependents onto client 0.3 and queue 0.24 Jul 31, 2026
@loks0n
loks0n requested a review from shimonewman as a code owner July 31, 2026 09:10
@loks0n
loks0n merged commit 41c426e into main Jul 31, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant