tests: fix api.test SFTP read target race

[ejohnstown]

• The test opened the listing's first regular file, which raced with tests/testsuite.test creating and removing files in the same directory under make -j check — the macOS -1062 flake. It now stages its own target over SFTP, selects it by name, and removes it afterward.
• Staging retries on WS_WANT_READ/WS_WANT_WRITE/WS_REKEYING and clamps writes to land exactly on WOLFSSH_MAX_SFTP_RW for any value of that macro; the listing assert, read block, and cleanup all key on Open success, so reads never target a stale file.
• Reads now verify the returned payload is the staged fill byte, not just a plausible length.

[Copilot]

Pull request overview

This PR updates the SFTP read API test to eliminate a directory-entry selection race under parallel test execution by staging a dedicated read target file over SFTP and validating the read payload contents.

Changes:

• Stage a deterministic SFTP read target file (write exactly WOLFSSH_MAX_SFTP_RW bytes) and select it by name from LS output.
• Add a payload validator (SFTP_CHECK_READ_PAYLOAD) to ensure reads return the expected fill byte, not just a plausible length.
• Clean up the staged read target after the test completes.

Suppressed comments (1)

tests/api.c:2833

• The LS retry loop has the same issue as the create loop: if it hits the 1000-try limit due to repeated WS_WANT_READ/WS_WANT_WRITE/WS_REKEYING, the test proceeds with current==NULL (and may end up skipping the read path if rdCreated is also false). It’s better to fail on timeout so the test doesn’t silently pass when the SFTP session is stuck.

Suggestion: after the loop, if current is still NULL, assert the last error wasn’t WANT/REKEYING (i.e., ensure the loop didn’t time out on transient errors).

        current = NULL;
        for (rdTries = 0; rdTries < 1000; rdTries++) {
            current = wolfSSH_SFTP_LS(ssh, (char*)currentDir);
            if (current != NULL) {
                break;
            }
            rdErr = wolfSSH_get_error(ssh);
            if (rdErr != WS_WANT_READ && rdErr != WS_WANT_WRITE &&
                    rdErr != WS_REKEYING) {
                break;
            }
        }

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #1142

Scan targets checked: wolfssh-bugs, wolfssh-src

No new issues found in the changed files. ✅

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (3)

tests/api.c:2932

• Cleanup Remove is currently unchecked. If it returns WS_WANT_* / WS_REKEYING, the pending RM state can interfere with the following WOLFSSH_TEST_INTERNAL write-path coverage (and may leave the temp file behind). Consider retrying until the remove completes and asserting success.

        wolfSSH_SFTP_Remove(ssh, rdName);

tests/api.c:2783

• wolfSSH_SFTP_Remove() can return WS_WANT_READ/WS_WANT_WRITE/WS_REKEYING and expects the caller to retry the same operation until it completes. Ignoring the return here can leave a pending RM state that may consume/expect packets while the following Open runs, reintroducing flakes.

This issue also appears on line 2932 of the same file.

        wolfSSH_SFTP_Remove(ssh, rdName); /* clear any stale file */

tests/api.c:2821

• wolfSSH_SFTP_Close() is also a stateful SFTP operation and may return WS_WANT_READ/WS_WANT_WRITE/WS_REKEYING. Not checking/retrying it can leave a pending CLOSE response that interferes with the subsequent LS/read operations (same underlying stream).

        wolfSSH_SFTP_Close(ssh, rdHandle, rdHandleSz);

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #1142

Scan targets checked: wolfssh-bugs, wolfssh-src

No new issues found in the changed files. ✅