This patch institutes limits for how much crash data can be stored in
terms of maximum number of crash events per day. If more events than the
limit are encountered, we record that a high water mark has been
encountered and we silently discard the payload of future events.
We chose to not increment the version of the store payload because no
clients are actively saving this data yet, so it doesn't make sense to
incur a version bump.
--HG--
extra : rebase_source : 3d5d92668b38e8b9c3c45e1a61a3a172b576e0a5
extra : amend_source : 71fffa0724450c5fe13563d2539813e9a831b3de
The initial implementation of this feature will write 3 distinct event
types and will only count occurrences of each. Future iterations of the
feature will capture more metadata, such as submission state and extra
crash annotations. These will not be included in this patch set.
DONTBUILD (NPOTB)
--HG--
extra : rebase_source : a1be4ceb6e06f2153d0927e50090c5f352b741d6
This patch introduces the concepts of the "crash data store" and "crash
event files." The "crash data store" is a data store containing
information about crashes. Data is added to this store directly through
a JavaScript API or by the presence of "crash event files." A "crash
event file" is simply an individual file containing information about
a crash event. These files are periodically scanned and their contents
are merged into the store.
Currently, no specific event files types are defined. This patch merely
begins to implement the infrastructure for dealing with them. Support
for specific crash events will be added in subsequent patches.
--HG--
extra : rebase_source : c58017b514f31c2823bc8ef4158a42bba758a9ab
