Closed tgeoghegan closed 8 months ago
Another example is that in handle_upload_generic
, we will log about public share and input share decoding failures at LOG_WARN
and HPKE decryption failures at LOG_INFO
. All of these are almost certainly client errors (e.g., mismatch between VDAF configuration in client and server) and shouldn't be generating noise in our logs.
We've since resolved these specific problems by moving the log statements to DEBUG, though we remain vigilant for excessive logging.
In
handle_create_collection_job
, if there's no batch ready for collection, we return aBatchInvalid
error (link). Then we log it at LOG_ERR. This winds up being helpful for debugging today, but if this is indeed a client error, we shouldn't log it at LOG_ERR (because we did nothing wrong and our team doesn't need to take action) and we probably shouldn't log at all, because storing those log statements costs money!Similarly, we log "Error handling endpoint" at LOG_WARN and "Finished handling request" at LOG_INFO.