Background
Follow-up to #69 (PR #70).
The distribute and transfer sub-actions accumulate their results across steps by newline-appending JSON into $GITHUB_ENV variables (FLY_DISTRIBUTE_RESULTS, FLY_TRANSFER_RESULTS), which the root action's post step reads to render the job summary.
PR #70 bounded the per-entry size by persisting only the fields the job summary renders (slim projections, dropping files[]/download_count for distribute and message for transfer). That removes the realistic failure mode.
Remaining concern
The mitigation does not change the underlying mechanism: the variables are still appended across every step, so total size grows with the number of distribute/transfer steps. With slim entries this is tiny in practice, but it's still technically unbounded against the Linux single-env-var limit (MAX_ARG_STRLEN, 128 KB) that caused #69.
Proposal
Stop using $GITHUB_ENV as the accumulator. Write the accumulated results to a temp file at a known path (e.g. under $RUNNER_TEMP) that the post step reads, which is not subject to MAX_ARG_STRLEN. $GITHUB_STATE is not a drop-in because state is scoped per action instance and the reader is a different action (the root post step), so a shared temp file is the cleaner approach.
This is the truly root-cause fix; the projection in #70 is a sufficient mitigation in the meantime.
Background
Follow-up to #69 (PR #70).
The distribute and transfer sub-actions accumulate their results across steps by newline-appending JSON into
$GITHUB_ENVvariables (FLY_DISTRIBUTE_RESULTS,FLY_TRANSFER_RESULTS), which the root action's post step reads to render the job summary.PR #70 bounded the per-entry size by persisting only the fields the job summary renders (slim projections, dropping
files[]/download_countfor distribute andmessagefor transfer). That removes the realistic failure mode.Remaining concern
The mitigation does not change the underlying mechanism: the variables are still appended across every step, so total size grows with the number of distribute/transfer steps. With slim entries this is tiny in practice, but it's still technically unbounded against the Linux single-env-var limit (
MAX_ARG_STRLEN, 128 KB) that caused #69.Proposal
Stop using
$GITHUB_ENVas the accumulator. Write the accumulated results to a temp file at a known path (e.g. under$RUNNER_TEMP) that the post step reads, which is not subject toMAX_ARG_STRLEN.$GITHUB_STATEis not a drop-in because state is scoped per action instance and the reader is a different action (the root post step), so a shared temp file is the cleaner approach.This is the truly root-cause fix; the projection in #70 is a sufficient mitigation in the meantime.