Page MenuHomePhabricator

Command died with status 255: ERROR 8: Array to string conversion
Closed, ResolvedPublic

Description

This message occurs when attempting to comment on a Maniphest task by email through the following steps (and possibly through other sequences):

  1. User reports bug via email that gets piped to scripts/mail/mail_handler.php
  2. Phabricator sends email to a Postfix alias (say, group@) that includes multiple people (say, A, B, and C)
  3. User A comments on task by replying all to Phabricator's email. He thus sends to both Phabricator and group@. This comment is posted successfully.
  4. User B comments on task by replying all to User A's email from previous step, which sends to both Phabricator and group@.
  5. User B's comment fails with this error message sent to user B:

Other error messages often occur through processes like this that involve aliases and replying all, and it would be great if that could be fixed, but I don't have details on that at the time. This particular form of error ("ERROR 8: Array to string conversion") seems to be new in the last few days.

I realize this is complicated to reproduce and I don't know how critical all the steps are. I am happy to provide additional information if you let me know what you want to know. Thanks!

Event Timeline

I (user B) also got this error message:

The first error is happening while we're trying to generate an error mail, so this maybe quite a deep rabbit hole, but that first surface error looks straightforward.

In the sense that I'm doing something wrong, or that it's a real bug but probably easy to fix?

"Array to string conversion" is a bug. Once that's fixed (by D14996), the user will start getting some kind of error email instead (the bad conversion was occurring while trying to compose an email to notify the user about an error). That error email may describe an upstream bug, or may describe user error. The stack trace doesn't have enough information for me to guess.

Great, thanks. I've been putting off opening a task about the various errors we get when trying to comment on tasks by email when they involve aliases and replying all, but I will do it next time.

The second (or third or fourth or whatever, depending on how we're counting) Conpherence issue I'm unsure about.

I think it is because you have some-list@domain.com cc'd, and also possibly have Phabricator configured to receive mail at that domain. Phabricator interprets username@domain.com to mean "send Phabricator user with username a Conpherence message", under the assumption that Phabricator will receive mail at a dedicated domain (like phabricator.mycompany.com), not at a root domain (like mycompany.com). See also here: T7477#111482

We should probably just remove this feature -- or, at a minimum, disable it until we have a chance to actually do an iteration on Conpherence -- as I don't think it's actually very useful or that anyone uses it, and that policy error suggests it may not even work.

Which feature do you mean to remove?

Can we make this work (reply all, basically) without Phabricator having to have its own subdomain?

(Allowing Phabricator to receive mail at domain.com and also having real mailing lists and users at that domain is still a bad idea, because the two namespaces will collide, but few normal addresses resemble Phabricator object addresses so the practical badness is low -- almost no one has D832@mycompany.com as a real address.)

I intend to remove username@domain.com causing interactions with Conpherence.

The way I thought it was supposed to work is that instead of addresses like D832@company.com, we'd use phabricator+D832@company.com and thus only have to reserve the phabricator@ address. Is that not viable?

Phabricator strips the prefix if it is present, but does not require it to be present, and attempts to route all mail for the domain it is given.

How is it even getting mail addressed to, say, jonah@company.com if the system's mail is handled by Postfix and the aliases file only pipes phabricator@ to the Phabricator script?

The mail looks like this:

To: phabricator+T123@mycompany.com
Cc: list@mycompany.com

It gets the mail because it's in the "To", but inspects all the recipients because it may need to route multiple addresses, silence mail it would send to users who are CC'd, etc. It sees list@mycompany.com in CC and acts on it because it is configured to be responsible for the mycompany.com mail domain. See also T7477.

Ah, that makes perfect sense. Thanks!

I also don't think it's wholly unreasonable to change the prefix rule to be stricter, but I think getting rid of the username@ stuff will moot it in all realistic cases. We could look at the rules after the next Conpherence update if we want to reintroduce the username@ rule.

Alright, I think you should get different behavior at HEAD for both of those issues. No promises it will be correct, but let me know if those changes just uncover a second series of errors.

epriestley claimed this task.

I'm going to close this out since I think there's no way for the upstream to move it forward for now, but file another issue if you hit a second wave of stuff or reopen this later if, e.g. all the fixes were terrible no-good garbage.