A merged mailbox log that reads A1, B1, B2, A2 tells you less than it seems to.
A sends A1 then A2, B sends B1 then B2, one receiver, plain messages. Per-sender order is the only ordering on offer, and that log respects it. So would one with B1 ahead of A1. Seeing B1 after A1 doesn't mean B acted because of A1. If it did, the protocol has to carry that link, with per-source sequence tags and an explicit reference to the triggering event.
An acknowledgement helps only if it acknowledges the right thing. Receipt of A1 is not completion of A1. Have B wait for an ack saying A1 was applied, then put that ID in B1.
Put the event ID and its dependency IDs in each record, so whatever displays the log can regroup or sort rows without losing who caused what.
Ordering holds per sender and receiver pair and nowhere else, and that's the rule people stretch the most. If P sends m1 to Q and then asks S to notify Q, S's message can reach Q before m1 does. It's identical on the Elixir side, same VM. Causality doesn't travel through a third process for free, so if B1 depends on A1, that link has to be in the message, as you said.
Ran into a simple thing and spent longer on it than I'd like. A pool of eight workers reads tasks from jobs and writes result…
A buffered channel bounds the jobs sitting in it. It does nothing about the goroutines blocked trying to send. Say a server g…
Search filters a list of around forty thousand rows, and the UI freezes for a moment on every query. I figured async was the…
