Part way through wiredtiger_open(), we stop using the event handlers provided as an argument to that call.

More specifically:

• Almost the first thing we do in wiredtiger_open() is to configure a dummy session that includes any event handlers that were passed into the wiredtiger_open() call. So at this point, any error messages (including panics) will call a configured handle_error() callback.
• Later in wiredtiger_open(), when we’ve constructed more of the world, we create the default session by calling __wt_open_internal_session(). This method always creates a session with NULL event handlers. So after this point in wiredtiger_open(), if something goes wrong, we will panic without invoking the application’s event handler.

This seems like a bug. A panic (or other error messages) anywhere during wiredtiger_open() should call the handle_error() callback.

suganthi.mani@mongodb.com hit this in some testing where she introduced an artificial panic when configuring the compressor extension. But since that happens after we create the internal session, it didn't call her event handler.

UPDATE: This assessment is wrong. It turns out that when we create a new session with a NULL event handler, that  means that a couple calls later we copy the calling session's event handler to the new session.

See discussion below for a more accurate description of the issue.