airvzxf / airvzxf/ftp-deployment-action

fix(lib): INPUT_MAX_RETRIES=0 (retry-forever) combined with v2.11.9 append-mode log lets the log file grow unbounded

オープン
#296 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る
area:lib.sh audit bug pending-design priority:medium
主要言語
Shell
スター
37
フォーク
9
平均マージ
44分
マージ済み PR(30日)
47

説明

## Finding

The v2.11.9 fix in `lib.sh:1074` switched `>` to `>>` so retries preserve their history. Combined with `INPUT_MAX_RETRIES=0` (the documented retry-forever sentinel) and the 5h hard timeout per attempt, the log file can grow to tens of MB across ~600 retries (30s backoff + ~5s lftp each).

When `INPUT_UPLOAD_LOG_ON_FAILURE=true`, this exceeds GitHub's per-artifact size cap and the artifact upload step itself fails with HTTP 413.

The non-zero retry path is also affected — `INPUT_MAX_RETRIES=10` (the default) plus a server that's permanently unreachable accumulates ~30-50 KB of identical error messages.

## Affected code

- `entrypoint.sh:344-415` (retry loop)
- `lib.sh:1074` (v2.11.9 append change)
- `lib.sh:1569-1665` (`upload_log_artifact`)

## Suggested fix

Either:

(a) Rotate the log on each attempt (rename `run-…log` → `run-…log.1` before each retry, keep the last N attempts).

(b) Cap per-attempt log size with `ulimit -f` or by running lftp under a wrapper that truncates at N MB.

(c) Keep only the last N attempts in the appended log by snapshotting the file size at the start of each retry and `tail -c`-ing the diff.

(d) Switch back to truncate mode (`>`) and write a separate `.history` file with one entry per attempt, for users who want the full history.

## Pending design decision

The right fix depends on what `upload_log_on_failure` is meant to deliver (last attempt only? full history? first failure only?). See related issue on the broken artifact endpoint — the upload may not work regardless.

## Source

F2 audit round (post-v2.11.9 release), 2026-09-06.

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

調査の方向性

Read the retry loop in entrypoint.sh:344-415, the append change in lib.sh:1074, and upload_log_artifact in lib.sh:1569-1665. Reproduce an unreachable-server run with INPUT_MAX_RETRIES=0 and INPUT_UPLOAD_LOG_ON_FAILURE=true, then resolve which log history upload_log_on_failure should provide. Done means the chosen behavior keeps logs within the artifact limit and the upload path is covered for both retry settings.

索引モデルが issue の本文から書いたものです。

評価

技術スタック
github-actions, shell
領域
ci-cd, devops
issue の種類
バグ
難易度
5/5
見積もり時間
1週間以上
活発さ
活発
明瞭さ
おおむね明確
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。