Autocomplete: More analytics tweaks

[philipp-spiess]

These are a few tweaks that hopefully makes us understand why in some niche situations with low n, we see so many accepted events.

I have not found anything in the logging that would explain it so far so I’m also going to include the log IDs (which are 100% anonymous) so we can cross match exactly what accepted event belongs to what completion.

• We now include the log id with all completion events
• The output console was cleaned up. The deleted logger calls were redundant information
• Completion suggestion events now have an additional accepted field
  • This field will be set in the same run loop as we also log the completion:accepted events and the idea here is that might not need two different event types but can instead simplify the logging to only one event per autocomplete request. This might also help us find out why we currently have more accepted events then desired.
• Unset the last candidate when the current candidate was accepted.
  • This is aimed to fix the "completion accepted without being suggested" events where we have <100 per day (very very low compared to the rest): https://sourcegraph.looker.com/x/9kGPrMNsHSqwhmow3F8wKf

Test plan

I removed a bunch of things from the output log and made sure the logging works as expected locally:

Screen.Recording.2023-08-10.at.10.52.21.mov

[dominiccooney]

The code looks good, but this from the description needs work:

Since completions will only be logged as accepted when they would also be logged as suggested in the same run loop, the number of suggestion events with accepted: true should match the number of suggested events. This logging will help us confirm that.

Could that phrase be simplified? It sounds like "all suggestions are accepted" which isn't right. It should be something weaker like "all suggested events have an accepted field", or "all accepted: true events have been read" ...something like that.

[philipp-spiess]

@dominiccooney Thanks @dominiccooney! I've updated the text above. This describes better what I had in mind:

This field will be set in the same run loop as we also log the completion:accepted events and the idea here is that might not need two different event types but can instead simplify the logging to only one event per autocomplete request. This might also help us find out why we currently have more accepted events then desired.

I also added that this is just additional for now.