As previously proposed in passing but I don't think ever getting its own bug, analyzers should have the ability to report errors as analysis records that can then be surfaced in the searchfox UI so that people don't need to grep the indexer log to find out why something is missing analysis data.

Bug 1789329 is a canonical example of this where the JS analyzer is getting upset about JS modules but the failure mode is non-obvious. If we had error records, these could potentially also serve as a call to action for users who might want to try their hand at fixing things, and we can enable this by having the UI generate a bugzilla search query against this component for an explicit "signature" which would ideally be the JS exception type for JS failures, etc.

We can also use this to support use-cases like the trace mechanism I had temporarily introduced for template analysis in these commits(1 2) where we added a "trace" record type where the value could indicate the kind of data contained in the trace record. It's probably preferable that our record's marker field instead be "diagnostic": 1 for consistency and to avoid making things harder for ourselves if we change our JSON rep.

The key fields would then probably be:

• severity: Taken from the tracing crate's Level struct: error, warn, info, debug, trace. Tracing is now mozsearch's canonical logging lib and it makes sense to operate in terms of its domain.
• schema: Defines how the rest of the structure beyond these key fields can be interpreted. This is to benefit tooling / templating which needs something to key off of. For situations where we're logging just a string message, "message" is the value we use.
• message: A human readable explanation for direct reporting if the schema was "message" or as a terse description of what's described if there is a schema suitable for display in a list to help locate a record of interest without having to dig deep into every record.
• signature: An optional string that constitutes what should be searched for in a bugzilla search to locate bugs to address any problems. This should always be present for "error" and "warn" levels since those need to be actionable at some level.
• group: An optional string to group records by, primarily intended to be used at the info/debug/trace levels.

For severity, this is something that would be an attribute of an indexing run and which would impact whether more detailed "diagnostic" records are emitted or not. For example, in the template prototype, the template records could be quite chatty and most of the time no one would be looking at them. So we'd default to a level of "warn" and trigger_indexer could take an optional command-line flag to change the severity. The same idea would apply to try-server runs for m-c so that MozsearchIndexer could be more chatty when desired, although that might need to be done in a spin-off.