apache / apache/openserverless
[CLI] Prerequisite failures are swallowed and stale markers bypass executable validation
- Lingua principale
- Python
- Stelle
- 576
- Fork
- 29
- Merge medio
- 50m
- PR unite (30g)
- 13
Descrizione
- [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
Guida per i contributori
Apri la guida per i contributori
Direzione di ricerca
Inizia in prereq.go, nelle funzioni ensurePrereq e downloadPrereq, quindi riproduci il caso del marker con ops ide undeploy su Linux amd64. Aggiungi la copertura per i file mancanti, vuoti e non eseguibili dietro un marker di versione e per la propagazione dei prerequisiti falliti; il lavoro è completato quando i marker obsoleti non bypassano la validazione e i task downstream si arrestano con un errore CLI utile.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- go
- Ambito
- cli
- Tipo di issue
- Bug
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Stato di attività
- Tranquilla
- Chiarezza
- Specificata chiaramente
- Idoneità per principianti
- 72/100