The server offers a traceExceptions server parameter (see https://www.mongodb.com/docs/manual/reference/parameters/#mongodb-parameter-param.traceExceptions) that configures the server to log full stack-traces for every DBException thrown. Server engineers use this feature to debug jstests, and some jstests temporarily configure the parameter to be set to add diagnostic information for difficult BFs.

However, in async code, because the same exception is often caught and re-thrown by the future library multiple times as it propogates down a continuation chain, this can lead to the same exception being logged with a complete stack trace many times. This clutters the log and can make it more difficult to understand the control flow induced by the exception.

We should consider omitting these re-throws from the stacktrace-logging requirement when traceExceptions is enabled. We could also consider a more general solution to try and only show the intial stack trace of an exception that may be caught and re-thrown with additional context multiple times.