Fix for swift test : _Concurrency/Executor.swift:357: Fatal error

[sebsto]

Fix the issue described at #640

Here is the proposed fix:

I added a new function assumeIsolatedOnEventLoop — a nonisolated method that:

1. Calls self.eventLoop.preconditionInEventLoop() to verify we're on the correct event loop (NIO's own thread-identity check, which always works)
2. Uses unsafeBitCast to strip the isolated annotation, the same pattern NIO uses internally and that I found on the Swift Forums.

See: https://github.com/swiftlang/swift/blob/main/stdlib/public/Concurrency/ExecutorAssertions.swift#L348

See: https://forums.swift.org/t/actor-assumeisolated-erroneously-crashes-when-using-a-dispatch-queue-as-the-underlying-executor/72434/3

[Copilot]

Pull request overview

Fixes swift test crashes on open-source Swift 6.2.3 toolchains built with +assertions by avoiding Actor.assumeIsolated in NIO callback contexts where Swift Concurrency can’t validate the current executor.

Changes:

• Add LambdaRuntimeClient.assumeIsolatedOnEventLoop, which validates isolation via eventLoop.preconditionInEventLoop() and then uses an unsafe cast to run an isolated closure.
• Replace two assumeIsolated call sites (closeFuture.whenComplete and connectionWillClose) with assumeIsolatedOnEventLoop.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[sebsto]

@adam-fowler if time permits, can you have a look at this and tell me if it makes sense? I'd like to check if my understanding is correct and if the fix, borrowed from NIO's project, is safe. Thank you

[adam-fowler]

@adam-fowler if time permits, can you have a look at this and tell me if it makes sense? I'd like to check if my understanding is correct and if the fix, borrowed from NIO's project, is safe. Thank you

I've not seen this in valkey-swift and we use a similar setup with an actor running on the event loop. But code looks fine