fix(queue): pass Redis DSN credentials to the publisher pool - #13588
fix(queue): pass Redis DSN credentials to the publisher pool#13588breken-ai wants to merge 1 commit into
Conversation
Sorry, something went wrong.
The shared Redis DSN carries _APP_REDIS_USER/_APP_REDIS_PASS and the cache/pubsub pools authenticate with them, but the publisher pool constructed its queue connection with host and port only, so every publish fails with NOAUTH on a password-protected Redis - and because the combined worker borrows the publisher pool for its consumer (worker.php), messages pile up as well. Pass $dsn->getUser() and $dsn->getPassword() through to Queue\Connection\Redis (both nullable; inert against current utopia-php/queue releases, live once utopia-php/queue#87 ships within the pinned ^2.0.0).
Greptile SummaryThis PR forwards Redis DSN credentials to the shared queue publisher connection.
Confidence Score: 4/5The PR is not safe to merge as the complete fix because locked installations still use a queue implementation that does not authenticate with the newly supplied credentials. One blocking failure remains: the application forwards credentials, but composer.lock retains the dependency version for which those arguments are inert, so authenticated Redis deployments continue failing with NOAUTH. Files Needing Attention: app/init/registers.php, composer.lock Important Files Changed
### Issue 1
app/init/registers.php:259-262
**Locked Dependency Ignores Credentials**
The locked `utopia-php/queue` version is still 2.0.1, whose Redis connection does not authenticate with these constructor arguments. Since deployments install from `composer.lock`, password-protected Redis instances will continue returning `NOAUTH`, leaving queue publishing and combined-worker consumption broken. The dependency lock needs a release containing the authentication implementation for this change to fix the reported failure.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "fix(queue): pass Redis DSN credentials t..." | Re-trigger Greptile |
Sorry, something went wrong.
| $dsn->getPort(), | ||
| $dsn->getUser() ?: null, | ||
| $dsn->getPassword() ?: null, | ||
| ); |
There was a problem hiding this comment.
Locked Dependency Ignores Credentials
The locked utopia-php/queue version is still 2.0.1, whose Redis connection does not authenticate with these constructor arguments. Since deployments install from composer.lock, password-protected Redis instances will continue returning NOAUTH, leaving queue publishing and combined-worker consumption broken. The dependency lock needs a release containing the authentication implementation for this change to fix the reported failure.
Knowledge Base Used:
Prompt To Fix With AIThis is a comment left during a code review.
Path: app/init/registers.php
Line: 259-262
Comment:
**Locked Dependency Ignores Credentials**
The locked `utopia-php/queue` version is still 2.0.1, whose Redis connection does not authenticate with these constructor arguments. Since deployments install from `composer.lock`, password-protected Redis instances will continue returning `NOAUTH`, leaving queue publishing and combined-worker consumption broken. The dependency lock needs a release containing the authentication implementation for this change to fix the reported failure.
**Knowledge Base Used:**
- [Initialization and request wiring](https://app.greptile.com/appwrite/-/custom-context/knowledge-base/appwrite/appwrite/-/docs/initialization-and-request-wiring.md)
- [Background processing and scheduling](https://app.greptile.com/appwrite/-/custom-context/knowledge-base/appwrite/appwrite/-/docs/background-processing.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
Sorry, something went wrong.
|
Closing this one out - the fix landed upstream in #13622 (with utopia-php/monorepo#260 on the queue side). @ChiragAgg5k's version covers the same ground plus the DSN encoding and the direct \Redis auth paths, so there's nothing left to add here. Nice fix. |
Sorry, something went wrong.
Fixes #13554.
Root cause
The shared Redis DSN (app/init/registers.php:51-57) carries _APP_REDIS_USER/_APP_REDIS_PASS, and the sibling pools authenticate with them ($redis->auth($dsnPass) in the default resource factory). The publisher pool, however, constructs its queue connection with host and port only - so against a password-protected Redis (requirepass / ACL), every publish fails with NOAUTH. Because the combined worker borrows the publisher pool for its consumer (worker.php, BrokerPool(publisher, consumer: publisher)), queue messages pile up too, which matches the reporter's task-scheduler symptoms exactly.
One layer down, utopia-php/queue's Connection\Redis accepts ?user/?password in its constructor but never calls auth() - the library half is fixed in utopia-php/monorepo#247 (composer pin ^2.0.0 admits the patch release).
Fix
The publisher pool passes the DSN credentials through ($dsn->getUser() ?: null, $dsn->getPassword() ?: null - the getters are already used a few lines up). Inert-but-correct against current utopia-php/queue releases (the constructor ignores them today); live as soon as utopia-php/monorepo#247 ships.
Verification
DSN construction, the authenticating sibling factory, the publisher pool construction, the worker.php pool borrowing, and the library constructor signature all confirmed in source at main (f31509d). Not run: no PHP runtime or live password-protected Redis in the author's environment - external red proof is the reporter's hourly NOAUTH log with every other pool authenticating.