I suspect the fatal error OpenAI saw was an "SSL error: decryption failed or bad mac"? Or if SSL were disabled, they likely would see the sort of parsing error

I suspect the fatal error OpenAI saw was an "SSL error: decryption failed or bad mac"? Or if SSL were disabled, they likely would see the sort of parsing error vaguely described as an "unrecoverable server error" due to streams of data from one request being swapped with another, with incorrect data structures, bad alignment, etc. I can see how if the stars aligned and SSL were disabled this data race would manifest in viewing another user's request, so long as the sockets were receiving similar responses when they were swapped. I suspect the issue is deeper than the bug recently fixed in just redis-asyncio. Libraries written prior to asyncio/green threads often have that functionality enabled by means of monkey patches or shims that juggle file handles or other shared state, and there are data races. When SSL is used hopefully those data races reading from sockets result in MAC errors and the connection is terminated. It's easy to imagine the same mistake happening one level up, in message passing code that manages queues or other shared data structures. Search for "python django OR celery OR redis OR postgres OR psycopg2 decryption failed or bad mac" and you'll see the scale of the issue, it's fairly widespread. I don't have a high degree of confidence in this ecosystem. I've written about this before on Hacker News[1], and I'm not confident in the handling of shared data structures in Python libraries. I don't think I can blame any maintainers here, there's a huge number of people asking for these concurrency features and the way that it's often implemented - monkey patching especially - makes it extremely difficult to do correctly. [1] https://news.ycombinator.com/item?id=31065472 https://news.ycombinator.com/item?id=31065472