Description

What is the purpose of this pull request?

This pull request:

• fixes markdown_links and markdown_src_attributes scheduled workflows, which have failed on every develop run since 2026-07-01 with Argument list too long
• replaces oversized env:-block payloads with quoted heredocs that write directly into the run script, avoiding the exec-time argument/environment size limit while preserving shell-injection protection
• fixes a malformed if: condition in markdown_src_attributes.yml that made the "Check status" step always run regardless of actual status

Related Issues

This pull request does not have any related issues.

Questions

None.

Other

Failing runs: 30675870949 (markdown_src_attributes, step "Log results"), 30675418090 (markdown_links, step "Check links against database"). Both fail with:

An error occurred trying to start process '/usr/bin/bash' with working directory '/home/runner/work/stdlib/stdlib'. Argument list too long

Root cause: #12741 (shell-injection hardening) moved broken-link/broken-image JSON payloads, sometimes exceeding 200KB, into step-level env: blocks. env: values are placed into the process environment table when the runner execve()s bash for the step. Linux caps individual argv/environ strings at MAX_ARG_STRLEN (128KB), so any payload larger than that crashes the spawn before the step body runs.

Fix: replace each env: VAR: ${{ steps.results.outputs.X }} + "$VAR" pattern in both workflow files with cat > file <<'DELIM' ... DELIM, writing the payload into the script body instead of the environment or argv. The heredoc delimiter is quoted, which disables parameter and command substitution on the body — untrusted $(...) or backtick content is written literally, never executed, so the injection protection from #12741 is preserved through a size-safe mechanism. Four call sites changed across the two workflow files. .github/workflows/scripts/markdown_links/create_broken_link_issues now takes a file path as its first argument instead of an inline JSON string, since passing the payload as a literal argv element hits the same size limit.

Second fix, same file: markdown_src_attributes.yml's "Check status" step had if: ${{ steps.results.outputs.status }} != 'success' — only the left-hand side is wrapped in ${{ }}, so the whole expression evaluates to a non-empty literal string and is always truthy. The step therefore always ran and always failed, but this was masked by the "Log results" crash happening first. Corrected to ${{ steps.results.outputs.status != 'success' }}, matching the form already used in markdown_links.yml.

Validation: YAML syntax checked for both workflow files (yaml.safe_load), bash syntax checked for the modified script (bash -n). Standalone reproduction confirmed the heredoc write produces byte-identical output to the old echo "$VAR" >> file approach across compact JSON, pretty-printed JSON, empty string, empty array, and trailing-newline cases, and confirmed shell metacharacters, $(), and backticks embedded in a payload are written literally and never executed.

Two residual items for maintainer attention, neither blocking:

• a payload line exactly matching the heredoc delimiter would truncate it early; not reachable today since the upstream stdlib-js/check-markdown-link-definitions-action always emits single-line JSON. That action is referenced via @main rather than a pinned SHA — pre-existing, not introduced here, but worth a separate look
• create_broken_link_issues now treats a genuinely empty failures file as "no broken links" (exit 0) instead of erroring; unreachable in the old code since the upstream action always emits at least [ ] for zero failures

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

AI Assistance

When authoring the changes proposed in this PR, did you use any kind of AI assistance?

• Yes
• No

If you answered "yes" above, how did you use AI assistance?

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Documentation (including examples)
• Research and understanding

Disclosure

If you answered "yes" to using AI assistance, please provide a short disclosure indicating how you used AI assistance. This helps reviewers determine how much scrutiny to apply when reviewing your contribution.

This PR was produced by an automated CI-maintenance routine. Root cause was identified via multi-agent investigation of the failing workflow runs, and the fix was independently validated by three separate reviewer agents (correctness, regression scope, style/conventions) before commit. A maintainer should still review before merging.

@stdlib-js/reviewers

Generated by Claude Code