runningRelease resolution logic flawed

[ryanbrainard]

This code determines this runningRelease:

let runningRelease = releases.filter((r) => r.status === 'pending').slice(-1)[0]

This logic depends on how many and which other releases are in releases. For example, in the example below, if there are 29 releases, the last two are pending (in JSON), so they are displayed the user as v289 being pending and v289 being release command executing.

$ heroku releases -a redacted-app -n 29
=== redacted-app Releases - Current: v316
...
v289  Set REDACTED1 config vars pending              user@salesforce.com           2017/08/24 03:20:03 +0900
v288  Set REDACTED2 config vars release command executing  user@salesforce.com           2017/08/24 03:19:52 +0900

However, by only fetching 28 releases, v289 changes to release command executing because it is now considered the runningRelease:

$ heroku releases -a redacted-app -n 29
=== redacted-app Releases - Current: v316
...
v289  Set REDACTED1 config vars release command executing              user@salesforce.com           2017/08/24 03:20:03 +0900

In addition to this problem, it is questionable why the last release is considered the runningRelease at all. Shouldn't API be getting this information from the runtimes? I don't see how the CLI would be able to determine this on it's own.

[dmathieu]

We added this logic a year ago, when we started work on preventing releases from running concurrently, but that work was canceled.

@jbyrum what do you think of always showing "pending" and never "release command executing"? cc @heroku/build

[jbyrum]

@dmathieu I think we need to discuss this one in person. Can we talk in our weekly build meeting?

[dmathieu]

We're going to be fixing this to always show "release command executing", and go back to the drawing board for preventing releases from running concurrently.