`null` messages are skipped. So are `None` and `unit` in F#

[Prunkles]

I would like to begin with a question: Are null messages actually allowed in this library?
I'm not sure, because I have multiple sources, and they all contradict each other:

1. The signature of the IContext.Message indicates that messages can be null:
   

   protoactor-dotnet/src/Proto.Actor/Context/ISenderContext.cs

   Line 25 in e453945

   object? Message { get; }

2. But if you try to send a null message from an actor to another, then the message apparently will be skipped. I digged a bit in sources, and found that I guess is the reason:
   

   protoactor-dotnet/src/Proto.Actor/Mailbox/DefaultMailbox.cs

   Lines 220 to 222 in e453945

   	msg = _userMailbox.Pop();
   	if (msg is not null)

   
   So null messages are successfully put in the mailbox, but are discarded during processing.
   But honestly, it seems more like a coincidence rather than a desired behavior. nulls are skipped here because _userMailbox.Pop() returned null, but it will do this, as we see by the code below, in two cases:
   

   protoactor-dotnet/src/Proto.Actor/Mailbox/UnboundedMailboxQueue.cs

   Line 19 in e453945

   public object? Pop() => _messages.TryDequeue(out var message) ? message : null;

   1. if the mailbox is empty (and this is an intended behavior);
   2. if the message happened to be null by its value.

   So maybe this behavior is actually a bug.

3. But, in spite of the 2. point, the null messages won't be skipped if they are sent to a Future, because they are not actors, therefore they don't have mailboxes with this strange behavior.

4. There is a PR prevent null messages #1145 that explicitly says that null messages should not be allowed, but it is in a different context of remote actors, so I am not sure if it is appliable here.

---

Anyway, this issue is about another problem. In F#, None (option) and () (unit) values are represented as null in runtime. So, if null messages are actually not allowed, then these very general and frequently used types become unusable, efficiently making the whole F# unusable for using this library.

[rogeralsing]

@codex research why we don´t allow null messages, I simply don´t recall other than null not really being a meaningful message. but do we have technical limitations for it?

at the very least, some form of sender/receiver middleware should be able to capture and use a surrogate value instead.

[chatgpt-codex-connector]

Findings (why null messages are effectively skipped today)

• The mailbox queue contract uses null as the sentinel for “no message.” IMailboxQueue.Pop() returns object?, and the default queue implementation returns null when the underlying queue is empty, which makes an actual null message indistinguishable from “empty.” src/Proto.Actor/Mailbox/Queue.csL9-L18 src/Proto.Actor/Mailbox/UnboundedMailboxQueue.csL11-L21
• DefaultMailbox treats null from _userMailbox.Pop() as “no more messages” and breaks out of the processing loop, so a null user message is never dispatched to the actor. src/Proto.Actor/Mailbox/DefaultMailbox.csL181-L239
• BatchingMailbox does the same via (msg = _userMessages.Pop()) is not null in its batching loop, so null can never be included in a batch either. src/Proto.Actor/Mailbox/BatchingMailbox.csL60-L96

How futures behave differently

• Futures don’t go through the mailbox queue at all. FutureProcess.SendUserMessage completes a TaskCompletionSource directly with whatever message was sent, so null values are preserved in that path (no “empty vs. null” ambiguity). src/Proto.Actor/Future/Futures.csL90-L155

Other behavior relevant to “null” messages

• Even if a null message is in-flight, ActorContext.Forward treats a null current message as an error condition (logs MessageIsNull and returns), which further cements “null is not a real message” in some actor flows. src/Proto.Actor/Context/ActorContext.csL181-L200

Conclusion / technical limitation

• The primary technical limitation is the mailbox queue API: Pop() returning null is the only “empty” signal. This makes null values unrepresentable as actual user messages for mailbox-backed actors, which is why they get dropped by design rather than explicitly rejected. src/Proto.Actor/Mailbox/Queue.csL9-L18 src/Proto.Actor/Mailbox/UnboundedMailboxQueue.csL11-L21 src/Proto.Actor/Mailbox/DefaultMailbox.csL181-L239
• If we want sender/receiver middleware to observe and possibly substitute a surrogate value, we’d need to change the mailbox contract (e.g., return a boolean + message, or use a sentinel wrapper for nulls) so “empty” is distinct from “null,” then pass null through to the invoker rather than treating it as “stop processing.” That would allow middleware chains to see and transform nulls. The current design prevents middleware from ever seeing nulls because they are dropped before invocation. src/Proto.Actor/Mailbox/Queue.csL9-L18 src/Proto.Actor/Mailbox/DefaultMailbox.csL181-L239

Commands used

• rg -n "null" src/Proto.Actor/Mailbox src/Proto.Actor/Context src/Proto.Actor/Process -S (to locate mailbox/context null handling). src/Proto.Actor/Mailbox/DefaultMailbox.csL181-L239
• sed -n '150,260p' src/Proto.Actor/Mailbox/DefaultMailbox.cs (to review mailbox processing logic). src/Proto.Actor/Mailbox/DefaultMailbox.csL181-L239
• sed -n '1,120p' src/Proto.Actor/Mailbox/UnboundedMailboxQueue.cs (to confirm Pop() behavior). src/Proto.Actor/Mailbox/UnboundedMailboxQueue.csL11-L21
• sed -n '1,160p' src/Proto.Actor/Future/Futures.cs (to confirm futures bypass mailbox queues). src/Proto.Actor/Future/Futures.csL90-L155
• sed -n '170,220p' src/Proto.Actor/Context/ActorContext.cs (to confirm Forward null handling). src/Proto.Actor/Context/ActorContext.csL181-L200

View task →

[Prunkles]

@rogeralsing

at the very least, some form of sender/receiver middleware should be able to capture and use a surrogate value instead.

Yeah, I tried something like this. I've implemented this as a sender middleware that wraps every null to a wrapper-type, and a receiver middleware that unwraps these wrapper-types back to nulls, and then putting these middlewares to every props. This does work for simple cases, but it's very fragile. For example, if I have some other process (e.g. a future), which doesn't have middlewares as a concept, and the process expects to receive some Option or Unit type exactly, then this approach fails because the wrapper-type cannot be cast to null implicitly. So I have to explicitly specify everywhere that I can expect this wrapper-type along with my desired type, and this is not nice