SwiftNIO needs a noassert mode, does this exist?

[taylorswift]

@Joe_Groff

If the code failed a precondition check, that means there was a serious programming error. If you disable these checks, then the only place for code to proceed into is undefined behavior, where security exploits and data corruption lie. As damaging as losing service is, it's not nearly as bad as corrupting or exfiltrating your customers' data.

i understand this argument, as i have often made it myself. however, there is a crucial difference between serious programming errors in code you (or your teammate) wrote, and serious programming errors in libraries.

if you hit a precondition failure in code your team is responsible for, there is only one sensible course of action: all hands on deck until the crash is fixed.

if you hit a precondition failure in libraries you depend on, you don’t have a ton of great options. “stop all operations until somebody in a completely different organizational hierarchy resolves the issue” is not a real course of action, it is more of a signal that you have fundamental supply chain issues and need to find a different supplier. if there are no alternative suppliers, then that means your venture is a dead end. i do not want our organization to become a cautionary tale that investors use to argue that businesses that use Swift on Server are doomed. this is obviously bad for us, and bad for the Swift community as a whole.

@Joe_Groff

Rather than try to eliminate assertion checks completely, it would be more realistic to talk about what we could do to make it so that handling and recovering from an assertion failure has lower overhead. Taking down a whole process is too severe for servers and many other applications, and it would be good for us to have some way to let a supervisor process wind down gracefully when one job runs into an unrecoverable situation.

a decent stop-gap would be to have some way to recover from fatalError and friends, as discussed in this thread: Testing fatalError and friends .

i think many developers are conceiving of it exclusively in terms of testing, but having some way of recreating a crashed MultiThreadedEventLoopGroup would also be valuable in production. however, it would be tough to separate crashes that happen in our code from crashes that happen in library code, because they all run on the same thread group. the goal is not to disable all precondition failures, just precondition failures in code we do not control.