apache / apache/openserverless

[CLI] Prerequisite failures are swallowed and stale markers bypass executable validation

Abierto
#213 0 comentarios 0 reacciones 0 asignados Ver en GitHub
bug
Lenguaje dominante
Python
Estrellas
576
Forks
29
Merge medio
50 min
PR fusionados (30 d)
13

Descripción

- [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

Guía de contribución

Abrir la guía de contribución

Línea de trabajo

Empieza en prereq.go, en ensurePrereq y downloadPrereq, y luego reproduce el caso del marcador con ops ide undeploy en Linux amd64. Añade cobertura para archivos inexistentes, vacíos y no ejecutables detrás de un marcador de versión, y para la propagación de prerrequisitos fallidos; el trabajo estará terminado cuando los marcadores obsoletos no omitan la validación y las tareas posteriores se detengan con un error de CLI útil.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
go
Área
cli
Tipo de issue
Error
Dificultad
4/5
Tiempo estimado
3-5 días
Estado de actividad
Tranquilo
Claridad
Bien especificado
Aptitud para principiantes
72/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.