Inbox truthfulness

Three separate inbox bugs, all fixed together, because they all came down to the inbox showing you something that was not true.

What changed

Inbox thread assignments could show the wrong person as responsible for a conversation. If ownership had changed hands, or the assignment logic picked up a stale identity, the inbox would display someone other than the actual assigned owner, which made it unclear who was supposed to be handling a reply. For a team sharing an inbox, that kind of mismatch can mean a reply sits unanswered because everyone assumes someone else has it, or two people end up responding to the same thread because the assignment shown did not reflect reality.

Unread counts could also drift out of sync with what was actually in your inbox, showing a number that did not match the threads genuinely marked unread. Depending on how threads were being read and updated, the count could over- or undercount what needed your attention. An inflated count makes an inbox feel more overwhelming than it actually is, and an undercounted one means you might miss something that genuinely still needs a response.

Separately, when a reply arrived that collided with a message already recorded as sent (the same message reaching the mailbox from two directions, essentially), mailbox sync could halt entirely for that connection instead of resolving the collision and continuing. That meant new mail could stop coming in until the underlying conflict was cleared, and because the failure happened quietly in the background, there was no obvious signal that a mailbox had stopped syncing at all.

All three are fixed. Thread assignment now reflects the correct owner. Unread counts stay accurate to what is actually marked unread. And a colliding reply is resolved without stopping sync for the rest of the mailbox, so one edge case no longer takes down the whole connection.

Each of these three issues had a different root cause inside the inbox system, but they shared the same effect on you: the inbox told you something that was not actually true about the state of your mail. Fixing them together closes out that whole category of correctness problem rather than treating each symptom in isolation.

How to use it

Nothing changes in how you use the inbox. These were backend correctness fixes, so the inbox should now simply show accurate information: the right assignee on each thread, an unread count that matches your unread threads, and mailboxes that keep syncing even when an edge-case message collision occurs.

If you previously noticed a mailbox that seemed to stop receiving new mail, or an unread count that looked off, this fix addresses the underlying causes. If you still see stale numbers, a manual refresh of the inbox should bring it current, since a page that loaded before the fix went live may still be holding onto older state until you reload it.

If you run a shared inbox across a team, it is worth doing a quick spot-check of thread assignments after this update, particularly on any threads that felt ambiguous before. You should now see the correct person listed as owner consistently.

If you noticed a mailbox that appeared to stop pulling in new replies, reconnecting is not necessary. The fix addresses the collision handling directly, so sync should resume normally for that connection going forward without you needing to disconnect and reconnect the mailbox.

Why it matters

An inbox you cannot trust is worse than no inbox at all, because you either double-check everything manually or you miss things because you assumed the numbers were right. Getting assignment, unread counts, and sync reliability right means you can actually rely on the inbox to tell you what needs attention and who owns it, which is the entire point of having a shared inbox in the first place.

The sync collision fix matters most operationally: a mailbox that silently stops syncing means replies pile up invisibly until someone notices something is wrong, which could be hours or longer depending on how often you check that specific connection. Resolving the collision instead of halting keeps mail flowing continuously, so a rare edge case in message matching does not turn into a real gap in your reply coverage.

Assignment accuracy has a direct effect on response time. If the inbox tells you a thread belongs to someone who is not actually responsible for it, that thread can sit for longer than it should, waiting for a person who was never going to pick it up. Fixing assignment closes that gap and gets replies to the right person faster.

Together, these three fixes are less about any single dramatic failure and more about restoring the baseline expectation that a shared inbox should meet: what it shows you should be true. That baseline is easy to take for granted until it slips, and easy to forget how much you rely on it once it is restored.

For teams that treat the inbox as the shared source of truth for who is talking to which prospect, these fixes matter beyond individual convenience. Misassigned threads and inflated or deflated unread counts can distort how a team allocates its attention across a whole day, sending people toward threads that do not need them and away from ones that do. Getting the underlying data right is what makes any triage process built on top of the inbox, whether that is a formal rotation or just informal team habits, actually work as intended.

The sync collision fix specifically protects one of the more important guarantees a mailbox connection is supposed to give you: that a connection, once made, keeps working continuously without you needing to monitor it. Discovering after the fact that a mailbox quietly stopped syncing days ago means you have to go back and figure out what, if anything, was missed during that gap, which is a far worse position to be in than the fix simply preventing the gap from happening at all.

Availability

These fixes apply to all connected mailboxes.