feat: More aggressively prune the Crashpad database #698
Conversation
| // complete database to a maximum of 8M. That might still be a lot for | ||
| // an embedded use-case, but minidumps on desktop can sometimes be quite | ||
| // large. | ||
| data->db->CleanDatabase(60 * 60 * 24 * 2); |
There was a problem hiding this comment.
2 days still seems a long time to me, why not immediate? Or are we at risk of removing unsent minidumps?
There was a problem hiding this comment.
crashpad has 3 states essentially: new, pending and completed. The function cleans pending and completed minidumps. I would have to look into what it does exactly on upload (create as new, move into pending when it starts uploading?)
Keeping the "most recent" minidump might be fair to do. At least the database should not grow seemingly unbounded.
There was a problem hiding this comment.
in theory crashpad tries to upload as soon as the crash happens right? so this will only find new or pending minidumps if that failed somehow. I guess 2 days is reasonable, it's just really though to come up with something that suits all :)
There was a problem hiding this comment.
I'd strongly prefer to wipe the minidumps as soon as they get uploaded.
What about making the parameters configurable though API calls?
It seems that the defaults in the crashpad_handler only trigger after a long 10min delay, and let the db grow to up to 128M by default. We generally do not care about older/completed reports at all, so make sure to aggressively prune them.