Interesting new details regarding the lockup error.

I wanted to understand if the problem is in Vapor, Fluent, or perhaps NIO so I re-implemented the little example with Hummingbird and its Fluent module: https://github.com/finestructure/hummingbird-lockup-repro

I ported the example with the same API and ran make post, which sends a post request with Rester. I got a crash in the server:

Swift/ContiguousArrayBuffer.swift:580: Fatal error: Index out of range
make: *** [run] Trace/BPT trap: 5

The index out of range is happening in the second precondition on line 77 in HBParser.swift:

    init(_ parser: HBParser, range: Range<Int>) {
        self.buffer = parser.buffer
        self.index = range.startIndex
        self.range = range

        precondition(range.startIndex >= 0 && range.endIndex <= self.buffer.endIndex)
        precondition(self.buffer[range.startIndex] & 0xC0 != 0x80) // check we arent in the middle of a UTF8 character
    }

(lldb) po range
▿ Range(7..<7)
  - lowerBound : 7
  - upperBound : 7

(lldb) po buffer
▿ 7 elements
  - 0 : 47
  - 1 : 116
  - 2 : 111
  - 3 : 100
  - 4 : 111
  - 5 : 115
  - 6 : 63

, which is /todos?. Not entirely sure where the ? is coming from, it's not in the initial request, but let's leave that aside for now.

Because I couldn't believe Hummingbird would crash on such a simple example I tried to run a post request with the shipping example todos-fluent via Rester and ... it crashed in the same place!

However, the todos-fluent example comes with a Paw file and running the post request from there ... works!

I inspected the difference in the requests between Paw and Rester and started eliminating some of the minor differences but that made no change.

Instead of trying to debug this I swapped Rester out of the repro steps in favour of curl. Now the Hummingbird example worked, and the lock-up was not reproducible. Apart from the weird crash when using Rester, Hummingbird performed just fine, processed all posts, gets, and even dumps in a loop.

On a hunch, I went back to the Vapor repro example and swapped out Rester for curl and ... the lockup does not reproduce anymore. Switching back to Rester does lock it up.

So it appears that the way Rester is making requests

• crashes Hummingbird
• causes Vapor to lock up

Now Rester shouldn't be doing anything esoteric: it's a Swift tool triggering web requests using URLSession.dataTask. Did I (having written Rester) somehow manage to create a Swift server nuke?

But even if the problem lies with my implementation in Rester, something similar must be happening in a Vapor server, because remember: we can bring the Swift Package Index server down when running web requests via Safari and dumping the Postgres database via pg_dump.

This example using Rester is purely a local way to reproduce the error.

It's unclear to me what exactly is going on but it certainly looks like there's a common root problem that affects both Vapor and Hummingbird - but in different ways.

Or maybe I'm just holding it very wrong, which is entirely possible 🤣

FYI @fabianfett @adam-fowler