`gh run list` shows unreasonable ELAPSED times for old entries

[andreasabel]

Entries that are old (e.g. older than a year) show a gargantum ELAPSED time in gh run list.

$ gh --version
gh version 2.33.0 (2023-08-18)
https://github.com/cli/cli/releases/tag/v2.33.0

$ git remote -v
origin	git@github.com:haskell-hvr/cassava.git (fetch)
origin	git@github.com:haskell-hvr/cassava.git (push)

$ gh run list
STATUS  TITLE                                                     WORKFLOW    BRANCH           EVENT         ID          ELAPSED       AGE
*       v0.5.3.0-r3: cassava 0.5.3.0 revision 3: allow text-2.1   Haskell-CI  text-2.1         pull_request  5992126997  8m44s         8m
✓       v0.5.3.0-r3 Build with GHC 9.8.1 alpha1 (tested locally)  Haskell-CI  master           push          5713252409  8m54s         27d
✓       Allow bytestring-0.12                                     Haskell-CI  master           push          5493203024  9m20s         Jul  8, 2023
✓       bytestring 0.12                                           Haskell-CI  bytestring-0.12  pull_request  5493141829  8m29s         Jul  8, 2023
✓       v0.5.3.0-r1: allow base-4.18 (GHC 9.6)                    Haskell-CI  master           push          4093454416  13m19s        Feb  4, 2023
✓       v0.5.3.0-r1: allow base-4.18 (GHC 9.6)                    Haskell-CI  ghc-9.6          pull_request  4093400289  11m25s        Feb  4, 2023
✓       [ #206 ] Deriving FromField/ToField instances             Haskell-CI  generic-field    pull_request  2656433729  9682h39m43s   Jul 12, 2022
✓       Release 0.5.3.0: CHANGES: testes with GHC 9.4             Haskell-CI  master           push          2645476104  9721h4m49s    Jul 10, 2022
✓       Release 0.5.3.0                                           Haskell-CI  cassava-0.5.3    pull_request  2645414046  9721h27m1s    Jul 10, 2022
✓       [ #206 ] Deriving FromField/ToField instances             Haskell-CI  generic-field    pull_request  2645398518  9707h35m25s   Jul 11, 2022
X       [ #206 ] Deriving FromField/ToField instances             Haskell-CI  generic-field    pull_request  2645314589  9721h59m49s   Jul 10, 2022
✓       Restrict CI to master branch                              Haskell-CI  master           push          2540266176  10093h22m25s  Jun 22, 2022
✓       Fix #213: Bump vector and other outdated dependencies     Haskell-CI  vector-0.13      pull_request  2540225483  10093h28m5s   Jun 22, 2022
✓       Bump CI to 9.0.2, 9.2.3 and 9.4.1 alpha2                  Haskell-CI  master           push          2499694501  10218h52m51s  Jun 15, 2022
✓       Allow text-2.0 and base-4.17 (GHC 9.4)                    Haskell-CI  text-2.0         pull_request  2496667986  10228h53m49s  Jun 14, 2022
✓       Bump CI to 9.0.2, 9.2.3 and 9.4.1 alpha2                  Haskell-CI  text-2.0         push          2496403019  10229h25m10s  Jun 14, 2022

E.g. the last run is claimed to have lasted >10229 hours. Not likely the case. ;-)

[samcoe]

@andreasabel Unfortunately the API does not provide an elapsed time for runs and thus we have to do a calculation between the created time and the updated time for a job and use that as the elapsed time. If the job gets updated for some reason after it has completed you can end up in this situation where the elapsed time is inaccurate. This is generally a rare occurrence though. As we are limited by the platform and API response there is nothing we can do from the gh side of things to address this bug.

[andreasabel]

@samcoe You could filter out improbable values, like runtimes of a year or more. Or just not display the ELAPSED time for runs older than a year.

[andreasabel]

I see, you compute the ELAPSED time as updatedAt - startedAt, and updatedAt might be something other than when the run ended.

$ gh run list --branch master --limit 10 --json displayTitle,startedAt,updatedAt,databaseId,headSha
[ ...
  {
    "databaseId": 4093454416,
    "displayTitle": "v0.5.3.0-r1: allow base-4.18 (GHC 9.6)",
    "headSha": "07269a2d1a313354ca6da237a502ea85ca8441fb",
    "startedAt": "2023-02-04T21:13:26Z",
    "updatedAt": "2023-02-04T21:26:45Z"
  },
  {
    "databaseId": 2645476104,
    "displayTitle": "Release 0.5.3.0: CHANGES: testes with GHC 9.4",
    "headSha": "fd168df89805fb0f66d9a8aab92abeb157a300c3",
    "startedAt": "2022-07-10T17:50:46Z",
    "updatedAt": "2023-08-19T18:55:35Z"
  },
 ...
]

The first entry here is ok with startedAt in the proximity of updatedAt, the second is not ok (more than a year between).

So, same suggestion @samcoe, display ELAPSED as N/A if the value is too big. Should be a one-liner.

[andreasabel]

Related:

• Action job completedAt - startedAt != reported running time #7788