Deprecate and remove Inbox actor

[Aaronontheweb]

Description

Inbox is a legacy feature that is rarely used in modern Akka.NET applications. We should deprecate it in v1.5.x and remove it entirely in v1.6.

Rationale

• Inbox is a blocking, synchronous API that goes against actor model best practices
• Modern alternatives exist: TestKit for testing, regular actors for production
• Low/no usage in the community
• Maintenance burden without clear value

Proposed Plan

1. Mark Inbox as [Obsolete] in v1.5.x with a clear deprecation message
2. Remove completely in v1.6.0
3. Update documentation to guide users to alternatives

Alternatives

For testing: Use TestKit's TestProbe
For production: Use regular actor communication patterns with Ask/Tell

[kpko]

Hi,

I'm not using inboxes actively in our current project, but I used them in a past project with Akka.net like this:

public override async Task SubscribeTasks(SubscribeTasksRequest request,
        IServerStreamWriter<ProtoTask> responseStream,
        ServerCallContext context)
{
    var inbox = Inbox.Create(_actorSystemService.System);
    context.CancellationToken.Register(() =>
            inbox.Send(_actorSystemService.TaskManager,
                new TaskManagerCommands.CancelSubscription(request.QueueName, request.WorkerId)));

    inbox.Send(_actorSystemService.TaskManager, 
            new TaskManagerCommands.Subscribe(request.QueueName, request.WorkerId));

    while (!context.CancellationToken.IsCancellationRequested)
    {
        var msg = await inbox.ReceiveAsync(TimeSpan.FromSeconds(10));
        if (msg is DeferredTask task)
        {
            await responseStream.WriteAsync(ToProtoTask(task));
        }
        else if (msg is Status.Failure { Cause: TimeoutException })
        {
            continue;
        }
        // ...
    }
}

This is in a GRPC service. I want to subscribe to messages from a specific actor, data should be pushed from the actor to the outside (grpc service). What would be the alternative to ReceiveAsync without Inboxes? Just a while(...) Ask(...) loop with a timeout?

Basically that's the use case mentioned in the docs:

the ask pattern can be a solution (see below), but there are two things it cannot do: receiving multiple replies (e.g. by subscribing an IActorRef to a notification service)

[Aaronontheweb]

@kpko thank you for this feedback. It is making me reconsider this issue.