tools/metrics/histograms/histograms.xml

Index: tools/metrics/histograms/histograms.xml
diff --git a/tools/metrics/histograms/histograms.xml b/tools/metrics/histograms/histograms.xml
index 043f500d600a1a5d7c49f032b7bcf7cb54450b84..448192f6e2b9e83efa4d6b0b34a5223961698906 100644
--- a/tools/metrics/histograms/histograms.xml
+++ b/tools/metrics/histograms/histograms.xml
@@ -83764,6 +83764,33 @@ To add a new entry, add it with any value and run test to compute valid value.
   <int value="19" label="RECOVERY_FAILED_META_NO_VERSION">

[Mark P, 2016/04/19 23:34:28]

Please add a sentence to the end of the Sqlite.RecoveryEvents description,
something to effect that those of these enum entries are subsets / included in
the counts of other enum entries.

[Scott Hess - ex-Googler, 2016/05/13 21:24:36]

Done.

[Scott Hess - ex-Googler, 2016/06/29 21:39:30]

Undone in favor of referring to the code.

     GetMetaVersionNumber() found no version row in meta table.
   </int>
+  <int value="20" label="RECOVERY_SUCCESS_AUTORECOVERDB">
+    sql::Recovery::RecoverDatabaseOrRaze() completed successfully.
+  </int>
+  <int value="21" label="RECOVERY_FAILED_AUTORECOVERDB_BEGIN">
+    Database was too broken to recover.

[Mark P, 2016/04/19 23:34:28]

"to recover" or "to attempt recovery"?
It looks like this error does not include the other detailed failures about
problems that can happen along the recovery process

[Scott Hess - ex-Googler, 2016/05/13 21:24:36]

Recovery was attempted, and it failed in setup.  I'll rephrase to be similar to
the other descriptions.
I don't know what this means.  Are you asking for someone to enumerate all of
the cases which prevented Begin() from succeeding?  Most of them are already
logged in the Init() section, namely RECOVERY_FAILED_OPEN_TEMPORARY,
RECOVERY_FAILED_VIRTUAL_TABLE_INIT, RECOVERY_FAILED_WRITABLE_SCHEMA and
RECOVERY_FAILED_ATTACH.

Which obviously implies you may want me to annotate those various items to
describe which other items are supersets and subsets of each other, etc.  I'm
going to pre-emptively argue against this (and maybe that I should unwind the
annotations just added).  I'm basically recording these as code coverage, so
there's literally no utility to understanding them in the abstract without
reference to the code.  It is easy enough to enumerate the places where a
failure can be detected, but many of them are challenging to quantify in the
abstract, and I'd rather not spend a week understanding how a particular failure
can happen if it has only ever happened 4 times in the fleet.

[Scott Hess - ex-Googler, 2016/06/27 21:35:38]

Just FYI, I don't consider this comment resolved, there's still disagreement.

[Mark P, 2016/06/27 23:20:13]

Acknowledged.

[Scott Hess - ex-Googler, 2016/06/29 21:39:30]

OK, WRT re-writing the histogram comment to indicate "this is coverage, look at
the code", I also omitted RECOVERY_FAILED_AUTORECOVERDB_SCHEMA in favor of the
independent subsets.  So those enums are now independent, but the entire set of
enums are not (due to table and db errors overlapping).

+  </int>
+  <int value="22" label="RECOVERY_FAILED_AUTORECOVERDB_SCHEMA">
+    Autorecover could not copy existing schema.
+  </int>
+  <int value="23" label="RECOVERY_FAILED_AUTORECOVERDB_SCHEMACREATE">
+    Autorecover could not create new db schema, subset of _SCHEMA.
+  </int>
+  <int value="24" label="RECOVERY_FAILED_AUTORECOVERDB_SCHEMASELECT">
+    Autorecover could not read corrupt db schema, subset of _SCHEMA.
+  </int>
+  <int value="25" label="RECOVERY_FAILED_AUTORECOVERDB_NAMESELECT">
+    Autorecover could not read table names to copy.
+  </int>
+  <int value="26" label="RECOVERY_FAILED_AUTORECOVERDB_TABLE">
+    Autorecover failed recovering a table.
+  </int>
+  <int value="27" label="RECOVERY_FAILED_AUTORECOVERDB_SEQUENCE">
+    Autorecover failed recovering sequence table.
+  </int>
+  <int value="28" label="RECOVERY_FAILED_AUTORECOVERDB_AUX">
+    Autorecover failed recovering triggers, views, or virtual tables.
+  </int>
 </enum>
 
 <enum name="SqliteStatsEnum" type="int">