Bug | repo-server-api mode streams files outside the chart, rejects on out-of-bounds symlinks

[noamyehudai]

Describe the bug

With --render-method=repo-server-api (env RENDER_METHOD=repo-server-api), the tool streams local working-tree files to argocd-repo-server via the GenerateManifestsWithFiles gRPC API. The streamed tarball appears to include paths well outside the chart directory being rendered, and argocd-repo-server's out-of-bounds symlink check then rejects the entire request before any rendering happens.

In our monorepo, every Application render fails identically with:

❌ Failed to render application via repo server: error="failed to render app <appname>:
   repo server returned error for content source 0:
   failed to receive manifest response: rpc error: code = Unknown desc =
   streamed files contains out-of-bounds symlinks.
   file: src/apps/<some-app>/public/avatars/<asset>.png"

The referenced file is a relative symlink under src/apps/:

src/apps/<some-app>/public/avatars/<asset>.png  →  ../../../../../assets/<co>/<asset>.png

Both endpoints exist in the repo and the symlink target resolves cleanly during a normal git checkout (e.g. when argocd-repo-server clones from GitHub itself, as it does in server-api mode). The chart we're rendering (infra/charts/argocd) doesn't reference src/apps/ or assets/ at all.

Same workflow on --render-method=server-api works fine. Switching to repo-server-api breaks every render across all three matrix environments (3/3 envs, 3/3 retry attempts each, deterministic), so this is not flake or timing — the symlink check kills the very first render of every Application.

Expected behavior

One of:

1. The tool streams only the chart directory and its referenced value-file paths, not the entire working tree. Files unrelated to the chart being rendered shouldn't be in the tarball.
2. If streaming a wider scope is intentional, follow symlinks before tarring so the security check sees the resolved file, not the symlink. (The target file is present in the same repo — just under a different top-level dir.)
3. Document that repo-server-api is incompatible with repos containing file symlinks under any streamed path, so users know to file-copy out before flipping the mode.

Standard output

✨ - render-method: repo-server-api
[...]
🤖 Patching N Applications from ApplicationSets (branch: main)
🤖 Patching N Applications from ApplicationSets (branch: refs/pull/.../merge)
🤖 Rendering Applications (timeout in 300 seconds)
❌ Failed to render application via repo server: error="failed to render app argocd [b|rendered-apps.yaml]:
   repo server returned error for content source 0:
   failed to receive manifest response: rpc error: code = Unknown desc =
   streamed files contains out-of-bounds symlinks.
   file: src/apps/<some-app>/public/avatars/<asset>.png"
[... same error for every Application, both base and target ...]
❌ Failed to extract resources
##[error]Final attempt failed. Child_process exited with error code 1

The same Application paths render fine under --render-method=server-api against the same repo, same commit, same argocd-config/values.yaml.

Environment

• Tool version: v0.2.8
• ArgoCD chart version: 8.6.4
• --render-method: repo-server-api (set via RENDER_METHOD env var)
• Runner: GitHub-hosted ubuntu-latest (2 vCPU)
• Repo shape: monorepo, chart at infra/charts/argocd/, unrelated file symlinks elsewhere in the tree (e.g. src/apps/.../public/avatars/... → ../../../../../assets/.../*.png)

Workaround

Stay on --render-method=server-api (the v0.2.x default). This is what we're doing for now.

Why we wanted to flip

server-api mode routes every render through argocd-server's REST API, which on a 2-vCPU runner becomes the bottleneck under CONCURRENCY=40 × ~110 Applications and produces a long tail of multi-minute timeouts. repo-server-api would bypass argocd-server entirely and (per #428's discussion) is also where multi-source \$ref rendering works correctly — both of which we need.

[dag-andersen]

@noamyehudai Thank you for reporting this 🙏 Please try the newest release v0.2.9 and let me know if that fixed the problem 🚀

For local Helm charts, the repo-server-api render method now streams only the chart directory instead of the whole branch root. That should avoid unrelated files elsewhere in the repository, including unrelated symlinks, from being included in the tarball sent to the repo server.
Kustomize, plugins, and Kustomize with Helm support still use branch-root streaming because they can depend on files outside the immediate app path.