apache / apache/openserverless
[CLI] Prerequisite failures are swallowed and stale markers bypass executable validation
- Vorherrschende Sprache
- Python
- Sterne
- 576
- Forks
- 29
- Ø Merge
- 50 Min.
- Gemergte PRs (30 T.)
- 13
Beschreibung
- [x] I have searched the [issues](https://github.com/apache/openserverless/issues) of this repository and believe that this is not a duplicate.
### Ⅰ. Issue Description
The CLI prerequisite bootstrap can report success even when a prerequisite installation failed, and a stale version marker can permanently hide a missing, empty, or unusable executable.
This was verified against \`apache/openserverless-cli\` commit [\`64d64963b761341bab2f08be6f7842e782d5b565\`](https://github.com/apache/openserverless-cli/commit/64d64963b761341bab2f08be6f7842e782d5b565), used by OPS \`0.9.1-2607111538.dev\`, and is also present on the current \`main\` branch.
### Ⅱ. Describe what happened
There are two related failure paths in \`prereq.go\`:
1. [\`ensurePrereq\` prints errors from \`downloadPrereq\` but always returns \`nil\`](https://github.com/apache/openserverless-cli/blob/64d64963b761341bab2f08be6f7842e782d5b565/prereq.go#L249-L274). Callers therefore continue as if setup succeeded.
2. [\`downloadPrereq\` trusts the \`-\` marker before validating the actual executable](https://github.com/apache/openserverless-cli/blob/64d64963b761341bab2f08be6f7842e782d5b565/prereq.go#L204-L209).
In the observed state:
- \`~/.ops/linux-amd64/bin/coreutils-0.0.27\` existed;
- \`~/.ops/linux-amd64/bin/coreutils\` was a zero-byte file;
- the marker caused later runs to skip installation;
- \`ops ide undeploy\` then emitted \`"coreutils": executable file not found in $PATH\` three times;
- the task finally reported the misleading secondary error \`bun 1.3.14 or greater not available\`, although Bun \`1.3.14\` was installed.
Related issue #96 covers detecting an update that leaves an old executable in place. This case is different because prerequisite errors are swallowed and a stale marker bypasses executable validation entirely.
### Ⅲ. Describe what you expected to happen
- A failed prerequisite installation must make \`ensurePrereq\` return an error.
- A version marker must only be accepted when the corresponding executable exists and is a regular, non-empty, executable file.
- A stale marker should be removed or ignored so OPS can reinstall the prerequisite.
- Downstream tasks should not run after prerequisite setup has failed.
### Ⅳ. How to reproduce it (as minimally and precisely as possible)
1. Install or initialize OPS on Linux amd64.
2. Leave \`~/.ops/linux-amd64/bin/coreutils-0.0.27\` in place.
3. Truncate the executable:
\`\`\`sh
: > ~/.ops/linux-amd64/bin/coreutils
\`\`\`
4. Run an OPS task whose setup declares \`coreutils 0.0.27\`, for example:
\`\`\`sh
ops ide undeploy
\`\`\`
5. Observe that prerequisite setup trusts the marker and the task continues with an unusable \`coreutils\`.
The same behavior can be reproduced by removing the executable while retaining the marker.
### Ⅴ. Suggested fix
- Return a wrapped error from \`ensurePrereq\` when \`downloadPrereq\` fails (either fail fast or aggregate errors).
- Validate the executable before the marker fast path.
- Remove stale markers when validation fails.
- Add tests for marker + missing executable, marker + zero-byte executable, marker + non-executable file, and a failed prerequisite task propagating to the CLI exit status.
### Ⅵ. Environment
- OPS CLI version: \`0.9.1-2607111538.dev\`
- CLI commit: \`64d64963b761341bab2f08be6f7842e782d5b565\`
- Task repository/branch: \`apache/openserverless-task:0.9.1\`
- OS/architecture: Linux amd64
Beitragsleitfaden
Rechercherichtung
Beginne in prereq.go bei ensurePrereq und downloadPrereq und reproduziere dann den Marker-Fall mit ops ide undeploy unter Linux amd64. Füge Tests für fehlende, leere und nicht ausführbare Dateien hinter einem Versionsmarker sowie für die Weitergabe fehlgeschlagener Voraussetzungen hinzu; abgeschlossen ist die Aufgabe, wenn veraltete Marker die Validierung nicht umgehen und nachgelagerte Tasks mit einem hilfreichen CLI-Fehler angehalten werden.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- go
- Bereich
- cli
- Issue-Typ
- Bug
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Aktivitätsstatus
- Ruhig
- Klarheit
- Klar beschrieben
- Anfängerfreundlichkeit
- 72/100