Issue #20514 has been reported by lakehs (Ashley Lake). ---------------------------------------- Bug #20514: Open3#capture3 does not receive correct exit code from Heroku but Kernel#system does https://bugs.ruby-lang.org/issues/20514 * Author: lakehs (Ashley Lake) * Status: Open * ruby -v: ruby 3.3.1 (2024-04-23 revision c56cd86388) [arm64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Heroku has a command-line switch for returning the exit code from a detached process to the calling terminal via their CLI. However, Open3 doesn't appear to receive this exit code properly: ``` ruby irb(main):007> command = 'heroku run "rails db:migrate:status | grep \"down \"" --exit-code -a remote_app' => "heroku run \"rails db:migrate:status | grep \\\"down \\\"\" --exit-code -a remote_app" irb(main):008> params = {} => {} irb(main):009> stdout_str, stderr_str, status = Open3.capture3(command, params) => ["", "Running rails db:migrate:status | grep \"down \" on remote_app... provisioning, run.2070 (Shield-M)\n", #<Process::Status: pid 34912 exit 0>] irb(main):010> status => #<Process::Status: pid 34912 exit 0> irb(main):011> status.exitstatus => 0 ``` In this case, since I know that there are no migrations with status "down", grep should return an exit code of 1, not 0. Running the same command with system gives the expected result: ``` ruby irb(main):025> command = 'heroku run "rails db:migrate:status | grep \"down \"" --exit-code -a remote_app' => "heroku run \"rails db:migrate:status | grep \\\"down \\\"\" --exit-code -a remote_app" irb(main):026> res = system(command) Running rails db:migrate:status | grep "down " on ⬢ remote_app... provisioning, run.9202 (Shield-M) # intermediate output snipped › Error: Process exited with code 1 › Code: 1 => false ``` Switching "up" for "down" in the above grep statement yields `true` for exit code 0 when called with Kernel#system. This doesn't happen locally, but since Kernel#system gives the right results but Open3#capture3 does not, I don't think the problem is on Heroku's end. -- https://bugs.ruby-lang.org/