For the second piece here

Within the conpherence application the participants column only shows the two remaining (active) participants in the thread, however when clicking on the 'messages' icon in the site header, the resulting dropdown menu listing the threads and participants, still displays the username for the user that left the thread.

That's currently by design. It shows the last 3 folks to participate, as opposed to some subset of the list of whose actively affiliated with the thread right this second. Whoever left will naturally fall off that queue as more participation occurs. This is up for debate / can change, but I'll defer to @chad on that as it feels bundled up with how we show people versus thread title more generally.

Fatal is badsauce though. Unfortuantely though, I can't reproduce it. Here's what I did:

1. Made a new conpherence with two users, A and B
2. Had user A comment
3. Had user A leave
4. Loaded thread with user B and it worked fine

What am I missing to get this to trip?

Ah ok, for part two, that now makes sense, we didn't realise that was the intention.

I am not at work at the moment and don't have access to the installation this occurred on, however the rough background is: We have this thread which originally contained two users, user A and user B. User A sent a message to user B, user B had replied and then both users had posted numerous messages (between 100-200).

Today, a reasonable time after the thread was created, a third user was added to the thread, user C. After user C was added, user B removed themselves from the thread, leaving user A and user C. At this point we noticed conference stopped updating and checked the logs.

The same actions happened in a second thread, which had a similar history as above, and I believe it causes the same fatal exception, so I think we did replicate it, but would have to check.

I think the "moe, larry, curly..." bit would be best if it was "moe: what moe said last..." (basically the last message in the thread, a little preview...) That would obviate this bug as we would just load the data very differently.

Sound good?

Although the behavior makes a somewhat-reasonable sort of sense when considered carefully, I'd personally expect removed participants to immediately vanish and would be equally confused about the behavior as implemented.

What do you think about the most recent message instead? (Regardless of the current participation status of whoever sent the most recent message?)

I'm maybe 60/40 on message being better than participants, but @chad might have stronger feelings. Agreed that it's not confusing to show a departed participant if their message is shown.

I'd prefer the title reflect the current state of the audience, so if someone is removed, the title should reflect that.

@chad - What do you think about the most recent message instead? (Regardless of the current participation status of whoever sent the most recent message?)

Instead or also? I like also.

[Photos Team]
moe: photos app is posted in the app...

[larry, moe]
curly: imma peace out of here...

or maybe I misunderstand by what you mean with instead?

Ah, sorry, let me clarify, but I think I mean also. In the messages dropdown, things display like this

$title
$subtitle

$title if not set is the recent participant stuff otherwise its the set title. $subtitle is always the "moe, larry, curly..." thing. Proposal is to change the $subtitle to most recent message always. Note I think $subtitle is only applicable in the messages dropdown view, though sometimes it ends up being the same as $title which we show all over.

I'm fine with that. Could we correct the $title too?

Yeah, the removed participants showing up thing has mere hours to live. :D

Hey,
I have just spun up a new instance of Phabricator using HEAD, and the following allowed me to recreate the error:

1. Create user1
2. Create user2
3. User1 sends message to user2
4. User2 replies to user1

Send some random messages (user1 sent 3 messages, user2 sent 5 messages)

1. Create user3
2. User1 adds user3 to thread
3. User2 removes themselves from thread

Edit: Send a message, from either user1 or user3 and error occurs

The stack trace is the same and the javaScript console displays:

[Error] Failed to load resource: the server responded with a status of 500 (Internal Server Error) (1, line 0)

Unless I messed things up, here is where we are at:

1. Fatal should be dead at HEAD
2. Once people leave they won't show up in the messages dropdown anymore at HEAD

What should still be done here

1. Change the "a, b, c..." subtitle to the most recent message. The underlying query will end up grabbing the latest N transactions for the ~10ish threads we show in that dropdown such that there's a chance we don't get any / enough transactions to render the most recent message for any given thread. In that case, will just fall back to the "a, b, c..." stuff.
2. Handle fetching code should get upgraded to handle list. This is a bit tricky since a huge chunk of handle loading is handled for us by PhabricatorApplicationTransactionQuery and we'd need to change that class a bit to user the $viewer to load handles.

No rush on swapping the handle stuff over, I figure we'll do that a piece at a time as it makes sense, sort of like the processRequest() -> handleRequest(AphrontRequest $request) change.

@btrahan, the internal 500 error is fixed on both our installs at HEAD. Appreciate the quick response and fix. I'll leave this ticket open as D12347 is marked as fixing this.