workflow:wait reports workflow is still running when it isn't

[mattdaniel]

Platform

(x) MacOS
( ) Linux
( ) WSL2

Installed Via

(x) Homebrew
( ) Apt Package
( ) Manually

PHP Version

( ) 7.4x
( ) 8.0
(x) 8.1

Terminus Version

3.3.0

Command Executed

terminus workflow:wait projectname.dev

Expected behavior

• Expect the correct status to be returned, including something like [notice] Workflow succeeded and the process exiting if there is no workflow running.

Actual behavior

• The command thinks that the latest workflow is still running, when it isn't and actually finished a long time ago.
• Command repeatedly reports this incorrect info until the max time is reached.
• Example output:

 [notice] Current workflow is 'Automated backup for the live environment'; waiting for 'Sync code on dev'
 [notice] Current workflow is 'Automated backup for the live environment'; waiting for 'Sync code on dev'
 [notice] Current workflow is 'Automated backup for the live environment'; waiting for 'Sync code on dev'

• Also note above that the environment is referring to live, but 'dev' was specified in the command.
• The workflow that workflow:wait believes is running, has been confirmed as finished both in the dashboard, or with terminus, e.g. terminus workflow:info:status projectname.dev (note the info below still seems to ignore the .dev environment requested):

 [notice] Showing latest workflow on projectname.
 -------------- --------------------------------------------- 
  Workflow ID    c768ec2e-99f8-11ee-b832-...        
  Environment    live                                         
  Workflow       Automated backup for the "live" environment  
  User           Pantheon                                     
  Status         succeeded                                    
  Started At     2023-12-13 20:47:08                          
  Finished At    2023-12-13 20:54:14                          
  Time Elapsed   427s                                         
 -------------- --------------------------------------------- 

Note: same behaviour happening in github actions using ubuntu, terminus-build-tools-plugin, and build:workflow:wait

[DarkteK]

I'm currently having the same issue:

Calling terminus workflow:wait --start 1715097376 --max 500 -- my-env
Notice: ] Current workflow is 'Sync code on my-env'; waiting for 'Sync code on my-env'
Notice: ] Current workflow is 'Sync code on my-env'; waiting for 'Sync code on my-env'
Notice: ] Current workflow is 'Sync code on my-env'; waiting for 'Sync code on my-env'
Notice: ] Current workflow is 'Sync code on my-env'; waiting for 'Sync code on my-env'
Notice: ] Current workflow is 'Sync code on my-env'; waiting for 'Sync code on my-env'
Notice: ] Current workflow is 'Sync code on my-env'; waiting for 'Sync code on my-env'
Notice: ] Current workflow is 'Sync code on my-env'; waiting for 'Sync code on my-env'
Notice: ] Current workflow is 'Sync code on my-env'; waiting for 'Sync code on my-env'

It never ends...
Any fix for this? please

[diegom-ciandt]

Also having this issue with Terminus 3.5.1 + MacOs + PHP 8.3.8
My plan is to test it on a Linux to confirm it.

[DarkteK]

I found a temporary solution on this:

      - name: Wait for Pantheon workflow to finish
        run: |
          while true; do
            status=$(terminus workflow:info:status <site>.<branch> --field=status)
            echo "Current workflow status: $status"
            if [[ "$status" != "running" ]]; then
              echo "Workflow has finished with status: $status"
              break
            fi
            echo "Waiting for 2 minutes before checking again..."
            sleep 120  # Wait for 2 minutes
          done

Your process may be completed in way less time by using this step

[greg-1-anderson]

workflow:wait was only designed for the use case when a specific commit is pushed, and you know that there will be a sync code workflow for it. This algorithm was recently improved to allow for the SHA for the desired commit to be specified. The recommended sequence of events are:

1. Make a commit
2. Note the sha for it via git rev-parse --verify HEAD
3. Record the current start time (seconds since epoch)
4. Push commit to Pantheon
5. Call workflow:wait, passing the commit sha via the --commit option, and the start time via the --start option

In this instance, Terminus will wait until the workflow for the specific commit to finish. Calling workflow:wait at other times or without these options might not produce the desired result. In particular, if you don't pass the start time, workflow:wait is going to assume that any existing sync code workflow that it sees is "old", and it therefore ignores it and waits for a newer sync code to start up.

[DarkteK]

workflow:wait was only designed for the use case when a specific commit is pushed, and you know that there will be a sync code workflow for it. This algorithm was recently improved to allow for the SHA for the desired commit to be specified. The recommended sequence of events are:

1. Make a commit
2. Note the sha for it via git rev-parse --verify HEAD
3. Record the current start time (seconds since epoch)
4. Push commit to Pantheon
5. Call workflow:wait, passing the commit sha via the --commit option, and the start time via the --start option

In this instance, Terminus will wait until the workflow for the specific commit to finish. Calling workflow:wait at other times or without these options might not produce the desired result. In particular, if you don't pass the start time, workflow:wait is going to assume that any existing sync code workflow that it sees is "old", and it therefore ignores it and waits for a newer sync code to start up.

Hi @greg-1-anderson , thanks for the answer!!
I just have two things to comment here:

1- Not to be rude or disrespectful but I think the commit param should be marked as required in order for the command work properly
2- I tried the command as you suggested but I got an error saying the commit param doesn't exists, I'll attach a screenshot: