Most probot implementations don't set started_at resulting in bad output from GitHub

Bug Report

probot derivatives generally fail to set started_at. This is fine for checks.runs calls when status!=completed, because afaict (and as confirmed by @tcbyrd), the GitHub endpoint fills in started_at with Date.now() for when the endpoint is called.

@tcbyrd writes:

looks like in the post route we don’t require it because we do this: data["started_at"] ||= Time.now.utc

This is less good for status=completed, because per checks.runs, completed_at is a mandatory field in that case, and unless the app is time warping, its value (also calculated from Date.now()) will be before the API endpoint is called, which results in things like:

• DCO Successful in -1m — DCO (in the Conversation view) — because the completed_at happens just before the started_at is calculated, and the basic subtraction results in a negative number (-1).
• ran ... days ago in less than 5 seconds (in the Checks view) — because the completed_at happens just before the started_at is calculated, and the basic subtraction results in a negative number (-1), and while that should result in -1 as with the other view, there seems to be some logic that says if delta < 5s -> show less than 5 seconds.

Expected behavior/code Templates should default to filling in the started_at field, and ideally there should be a warning if it isn’t filled in so that app authors discover that they should fill it in.

Environment

• Probot version(s): master
• Node/npm version: unknown
• OS: all

Possible Solution Adjust template, add warnings.

Additional context/Screenshots DCO (Conversation view):

Prosebot (Checks view):

– This is mostly a place to hang fixes for individual apps, and also, perhaps, for @tcbyrd to update us on when the API endpoint is improved.

[tcbyrd]

The negative numbers should be resolved now on the github side. We still recommend providing it when necessary, but now in these scenarios where the check completes that quickly, we just don’t show any time-related data. Can we close since it started with “bad output from GitHub” and start a new tracking issue if we want to improve things with hooks beyond that?

[gr2m]

What I’d suggest to do is set a before request hook on the Octokit instance passed to the event handlers. It does two things

1. Keeps track of the time the event was received
2. It checks if a request creates a check run. If it is, default the started_at timestamp to the time from 1. if it’s not set by the user.

This is an interesting topic, thanks for bringing that up. I’ll discuss it with the other Octokit maintainers, too. It might be good example for sth the Octokit libraries could take care of in a standardized way. I’ll bring it up with the docs team, too, maybe we should add a note to https://developer.github.com/v3/guides/best-practices-for-integrators

<div>GitHub Developer</div><div>Best practices for integrators</div><div>Get started with one of our guides, or jump straight into the API documentation.</div>