using the new async APIs requires a paradigm shift. instead of sending EventLoopPromises across concurrency domains via AsyncStreams, it’s a lot more natural to just use native swift actor isolation.
given a use case such as: triggering a network fetch when receiving a server request, i am discovering the new APIs are colliding headfirst with the reality that ClientBootstrap is not Sendable.
which means… you cannot store anything that wraps a ClientBootstrap anywhere in an actor. why? because actors are re-entrant, and if you call any async functions that touch that ClientBootstrap, you are effectively sharing it across concurrency domains, and you will rightly get clobbered with concurrency warnings.
anyway, these aren’t new complaints, and people using ClientBootstraps with swift concurrency for different reasons than me have already been running into this problem for a while. for now i’ve just resorted to building a new ClientBootstrap on every request, since that avoids any sharing problems. but i really hope adoption of the new async APIs will put the final nail in the coffin for ClientBootstrap. this type has no place in the async/await world and i personally think replacing it should be the next priority for NIO.