Phabricator Emails Queue is blocked
Categories
(Conduit :: Phabricator, defect, P2)
Tracking
(Not tracked)
People
(Reporter: mhentges, Assigned: mhentges)
Details
(Keywords: conduit-triaged)
Attachments
(1 file)
Logs say that the server is 500-ing with the error: Return value of PhabricatorUserStore::find() must be an instance of PhabricatorUser, null returned
The queue will remain blocked until this is resolved.
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
We should be able to do a Phabricator deployment today.
I'm currently working on resolving the issue - as of now, I have a local reproduce. Patch should be up in under 30 minutes.
Assignee | ||
Comment 2•3 years ago
|
||
There had been an assumption that subscribers are always plain
PhabricatorUsers. However, it's possible for them to be
"projects" (group subscribers) or "packages" (code owner subscribers),
in which case the previous code would fail.
This uses similar logic to read subscribers as for reading reviewers.
There's some very similar code between the two implementations,
but the alternative would probably require multiple "type
disambiguation" checks, which (IMHO) would be worse.
Assignee | ||
Comment 3•3 years ago
•
|
||
Hah, 1672239 was specifically implemented to reduce the severity of these kinds of errors by falling back to a "minimal email" implementation and sending that to affected users.
However, the bug here is in the minimal-email resolution code, which is why this is stopping the queue instead of gracefully continuing to work. What great luck.
Assignee | ||
Comment 4•3 years ago
|
||
Patch has landed, currently collaborating with DKL for an upcoming release.
Assignee | ||
Comment 5•3 years ago
|
||
Patch has now been deployed to prod, the queue is now being drained and emails are being sent.
Description
•