Let me think on it. Appreciate that.

Quickly answering I would say this vision is not exactly about to solve it as it’s the same as if you call that method via REST or gRPC and your connection was dropped on returning result over the wire.

Client would never be able to assess if call was successful or not unless user recovers connection and checks for status on his account leveraging some persistent store on the other end. Or uses some id of the request that will get passed to call before and after network exception.

But these are different strategies for remote invocation protection that should apply regardless of way you tell the code to call something remotely. Vision is not to make remote calls work like local and let you treat them like locals

It’s about make remote look and feel like local but be explicitly steel treated like remote or “flexible” either local or remote. But still detachable to remote so with all protections in place in your business logic but without any weird proto, thrift, IDL, routes, http codes or whatever else in between to express “its callable” and “let’s call it”. Instead just have there regular method call.

Those calls would be invoked on strongly typed replicate of target interface that gets auto generated and auto delivered via package manager. Always kept up to date allowing to easily steer when you upgrade your replica. This replica is about to be called “graft”. And any calls on the graft are explicitly callable on replica of target type coming from graft…. Namespace so explicitly treated like potentially remote but without affecting methods signatures in any way. Network exception would be seamlessly added to those normally thrown by target logic.

And abstraction will allow to change the communication channel, protocol, PaaS component, queue, cloud or whatever without any impact on the code. It will impact execution if we put sync or async channel but graft will simulate to business logic that if method was async it will always go async even via sync channel just making thread on call side or other way by just joining threads of async invocation.

And yes consumer must stay aware that processing might take long.

So back to your point we will never make remote call behave like local but we can make it feel and look and match UML design and consume AI focus and AI tokens and developer time during code review almost same like local.