apache / apache/openserverless
[CLI] Prerequisite failures are swallowed and stale markers bypass executable validation
- Langage dominant
- Python
- Étoiles
- 576
- Forks
- 29
- Merge moyen
- 50 min
- PR mergées (30 j)
- 13
Description
- [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
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
Commencez dans prereq.go au niveau de ensurePrereq et downloadPrereq, puis reproduisez le cas du marqueur avec ops ide undeploy sous Linux amd64. Ajoutez des tests pour les fichiers manquants, vides et non exécutables derrière un marqueur de version, ainsi que pour la propagation d’un prérequis en échec ; le travail est terminé lorsque les marqueurs obsolètes ne contournent pas la validation et que les tâches en aval s’arrêtent avec une erreur CLI utile.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- go
- Domaine
- cli
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- Calme
- Clarté
- Clairement spécifiée
- Accessibilité débutants
- 72/100