Unexpected behavior in sf run apex test

[Cerelius]

Hello, I use a custom GitHub action to execute apex tests in my CI/CD pipeline that wraps the sf/cli and I've just made an update that uncovered some unexpected behavior for me and I wanted to ask if it's intended or not. And, potentially improve my understanding or put eyes on it.

In most asynchronous commands on the sf-cli I'm expecting to enqueue the operation through the command and then be able to reach out to check on the status using the job-id. For example, with a package install request the install is queued and then I am provided an id to let me check the status of the job. It will tell if it's in progress, completed, failed, etc. Providing a wait param will instead poll and wait for me until the job is complete or the wait times out.

I've had to update my action because we found that the --wait parameter on this command does not throw a failure when the waiting period times out. It provides an exit 0 and no indication that it timed out so it provides a false positive when using only the wait parameter.

Okay, to account for that we can just run without a wait and call out to get the current status of the test run. We've done that previously when creating a 2GP package version through a local polling system until the status is complete. However, I found that the sf apex get test command will sit and wait until the tests results are back to return a result. I've only been able to get it to return a complete pass or fail, never an in progress status. I've tried to catch an in-progress status with several different size packages and it's waited until the test completes every time. Curiously, this approach also looks to be significantly faster than running sf apex run test with a wait included.

Running the same set of tests using a test-suite, we received test results in 5-8 minutes using sf apex run test with no wait and immediately requesting sf apex get test. Compared to 18-35 minutes when running sf apex run tests with a sufficient wait time.

There's no blocker present here but the behavior is surprising and appears to contrast other behavior within the CLI in my experience.

• Is this intentional?
• Is this performance difference real or am I missing something here?