airvzxf / airvzxf/ftp-deployment-action
fix(entrypoint): INPUT_MAX_RETRIES=0 + 5h timeout per attempt = unbounded total runtime
- Linguagem predominante
- Shell
- Estrelas
- 37
- Forks
- 9
- Merge médio
- 44min
- PRs com merge (30d)
- 47
Descrição
gh issue create --title "fix(entrypoint): INPUT_MAX_RETRIES=0 + 5h timeout per attempt = unbounded total runtime" --label "bug,audit,priority:high" --body "## Finding
When INPUT_MAX_RETRIES=0 (retry forever), each attempt can run for up to the timeout (default 5h, configurable). Without an upper bound on the total number of retries, the action can run until the GitHub Actions job timeout (6h). On a self-hosted runner with no job timeout, the action runs indefinitely and exhausts the runner.
INPUT_MAX_RETRIES=0 means 'retry forever' (per the action.yml description). It should also cap the total wall-clock time, not just the per-attempt time.
## Affected code
- entrypoint.sh — retry loop around run_lftp_once
## Reproduction
1. Set INPUT_MAX_RETRIES=0 (or omit it; default may be 0).
2. Point the action at a server that always times out.
3. Observe the action retries for the full job timeout.
## Suggested fix
Either:
- Cap total retries with a separate INPUT_MAX_TOTAL_TIME / INPUT_MAX_TOTAL_ATTEMPTS input.
- Or, when INPUT_MAX_RETRIES=0, compute a sensible default (e.g. min(20, job_timeout / per-attempt-timeout)).
- Or, document that INPUT_MAX_RETRIES=0 means 'retry until job timeout' and require the caller to set an explicit job-level timeout.
## Source
F2 audit 2026-09-03 (entrypoint.sh audit). Reporter: subagent-pekodbj7.
## Related
- Part of EPIC #[epic-number]
- Closes: #NONE (no existing issue)
- Related: #49 (max_retries=0 should mean 'retry forever') — already closed; this is the residual"
Guia de contribuição
Nenhum guia de contribuição indexado para este repositório
Avaliação
Esta issue ainda não foi avaliada.