I'm not yet decided how to guard the input.
Introducing async_trait for a future proof of Handler trait is what I prefer but it could mean harm to SyncActor usage.
Use an extra closure would not break but with more boilerplate.

Edit: Use a closure for guarding input for now.

So what's the path forward for this PR. Is it ready for review and if so which parts should be focussed on.

A note after skimming over a couple files: a few fns are documented with "do not expose to public api". Are these fns better as unsafe? Also consider documenting the invariants that must be upheld regardless.

Hard to say it's ready as it's pretty hard to test the unsafes added. It would need some really edge cases to see if it holds up.

Context::wait_concurrent is just a method to push 'static lifetime future to actor's context. It's like actix_rt::spawn on an actor and they are safe. It' just not suggested to be used in public API.

The unsafe code only affect people who actually call ResponseAsync in handler. For people avoid using it there is no actual change to the code base other than a few more Vec::len check against an empty vector.

Making this a draft for now until proper tests are added.

I have reverted most changes related to actor context. Making AsyncResponse an AtomicResponse similar feature that uses unsafe to permit borrowing actor and context in async block.
It's supposed to work exactly like AtomicResponse but async/await friendly.

definitely excited about this but i think we should do a release without it first

Agreed. I'm not confident in this either.

There are still small issues to this approach so it's more like an experiment for the Concurrent variant AsyncResponse.

After some additional tests I find there is no way to actively go into stopping state during an async response actor future.

lmk if you want a review of this now

@robjtede I think this is ready for review.

I don't have time to keep this PR up to date anymore. It's welcomed to step in and take charge of it.