Batch and deduplicate action resolution across composite depths

[stefanpenner]

Summary

• Cache resolved actions across recursion depths — same action resolved once
• Batch-resolve sibling composites' sub-actions in one API call instead of N
• Defer pre/post step registration until after recursion (fixes HasPre/HasPost correctness)

Internal workflow with ~30 composites: ~20 resolve API calls → 3-4. Also reduces 429s (#4232).

Fixes #3731

Other possibilities

• Eager BFS resolution: pre-resolve all reachable actions upfront #4297 performs even better (~2x faster in my tests) when there are more nested downloads, but it's a larger refactor. Which may or may not be appealing to the maintainers.

Smoke test results

Tested with a self-hosted runner built from this branch vs stock (main), using a 50-action composite tree across 6 repos with 5 depth levels.

Action graph:

workflow → 10× L1 composites + 5 leaves (15 top-level steps)
  L1 (×10) → 1 leaf + 3 L2 composites (heavy cross-referencing)
  L2 (×10) → 1 leaf + 3 L3 composites
  L3 (×10) → 2 leaves + 2 L4 composites (cross-repo refs to 5 shard repos)
  L4 (×10) → 3 leaves (cross-repo refs)

Results (run)

	Stock runner (main)	This PR
Resolve API calls	311	4
Resolution time	70.6s	8.2s

• 78× fewer API calls, 8.6× faster action resolution
• Output parity confirmed (3845 leaf-action log lines in both runners)
• All composites resolved and executed at all 5 depth levels
• Cross-repo references resolved correctly
• Dedup verified: same owner/repo@ref never re-resolved across depths
• Batching verified: distinct repos at the same depth batched into 1 call

Earlier run (single-repo, same-ref tree)

Run: 311 → 1 resolve calls (all 50 actions shared the same owner/repo@ref lookup key, so the cache eliminated every call after the first).

Test plan

• 4 new L0 tests covering batching, cross-depth dedup, multi-top-level, and nested containers
• Smoke test with self-hosted runners: 50-action/5-depth/6-repo composite tree (see above)

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR optimizes action resolution in composite action trees by batching and deduplicating API calls across recursion depths. Instead of resolving sub-actions one composite at a time (N API calls), it collects all sub-actions at each depth level and resolves them in a single batch call, with a cross-depth cache to avoid re-resolving the same action. It also defers pre/post step registration until after recursion completes.

Changes:

• Introduce a stack-local resolvedDownloadInfos cache to deduplicate action resolution across composite depths, and a new ResolveNewActionsAsync helper that skips already-cached actions
• Collect composite sub-actions into a nextLevel list and batch-resolve them before recursing per parent group
• Defer pre/post step registration to after recursion so that HasPre/HasPost reflect the full subtree

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/Runner.Worker/ActionManager.cs	Core optimization: adds resolution cache, batch pre-resolution of next-level actions, deferred pre/post registration, and new ResolveNewActionsAsync helper
src/Test/L0/Worker/ActionManagerL0.cs	5 new L0 tests covering batching, cross-depth dedup, multi-top-level, nested containers, and parallel downloads

---

You can also share your feedback on Copilot code review. Take the survey.

[Copilot]

Pull request overview

This PR optimizes action resolution in the GitHub Actions runner by introducing batching and cross-depth deduplication for composite action resolution. Instead of making individual API calls per composite action at each recursion depth, sub-actions from all composites at the same depth are collected and resolved in a single batch API call. A stack-local cache ensures the same owner/repo@ref is only resolved once even if it appears at multiple depths in the composite tree. Pre/post step registration is deferred until after recursion to ensure HasPre/HasPost reflect the full subtree.

Changes:

• Added a case-insensitive resolvedDownloadInfos dictionary that caches resolved action download info across recursion depths, with a ResolveNewActionsAsync helper that skips already-cached actions
• Refactored PrepareActionsRecursiveAsync to collect composite sub-actions into a nextLevel list, batch-resolve them in one API call, then recurse per-parent group — moving pre/post step registration after recursion
• Added 5 new L0 tests covering batching, cross-depth dedup, multiple top-level actions, nested containers, and parallel downloads

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/Runner.Worker/ActionManager.cs	Core optimization: batch resolution cache, ResolveNewActionsAsync helper, deferred pre/post registration
src/Test/L0/Worker/ActionManagerL0.cs	5 new tests validating batching, deduplication, multi-action, nested container, and parallel download scenarios

---

You can also share your feedback on Copilot code review. Take the survey.

[stefanpenner]

@ericsciple any interest in #4297 or is that too invasive?

[Copilot]

Pull request overview

This PR optimizes GitHub Actions runner action resolution for composite actions by batching resolve requests and caching resolved download info across composite recursion depths to reduce API calls and avoid 429s.

Changes:

• Add a feature flag (actions_batch_action_resolution) and an opt-in env var (ACTIONS_BATCH_ACTION_RESOLUTION) to enable batched, cached action resolution.
• Implement a new recursive preparation path that batch-resolves next-level sub-actions and defers pre/post registration until after recursion.
• Add new L0 tests covering batching and cross-depth dedup behaviors.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/Runner.Worker/ActionManager.cs	Introduces the batched/cached resolution path behind a feature flag + env var and adds a cache-aware resolve helper.
src/Runner.Common/Constants.cs	Adds the BatchActionResolution feature flag constant.
src/Test/L0/Worker/ActionManagerL0.cs	Adds multiple L0 tests for the new batching/dedup behavior when the env var is enabled.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

[Copilot]

The comment claims this test verifies concurrent downloads via Task.WhenAll, but the assertions only check that watermarks exist after PrepareActionsAsync completes; that would also pass with fully sequential downloads. Either strengthen the test to actually detect overlap/concurrency (e.g., using synchronization in the download mock to prove parallel execution), or reword the test/comment to match what it really validates.

[Copilot]

This test comment refers to DownloadActionsInParallelAsync as the “parallel code path”, but that method doesn’t exist in the codebase (and ActionManager doesn’t appear to use Task.WhenAll for downloads). This is misleading for future maintainers—please update the comment (and/or test name) to describe the actual behavior being validated.

Suggested change

	// Verifies that multiple unique top-level actions are downloaded via
	// DownloadActionsInParallelAsync (the parallel code path), and that
	// all actions are correctly resolved and downloaded.
	// Verifies that when batched action resolution is enabled via
	// ACTIONS_BATCH_ACTION_RESOLUTION, multiple unique top-level actions
	// are resolved together and downloaded, and that all actions are
	// correctly resolved and downloaded.

[ericsciple]

@stefanpenner I am comfortable with the changes. I am checking with @TingluoHuang if he has any concerns before merging.

[stefanpenner]

@ericsciple keep keep me posted, happy to jump in and make changes as needed.

Any interest in #4297 or is that (as I assumed) too invasive?

[ericsciple]

Any interest in #4297 or is that (as I assumed) too invasive?

Regarding #4297, unbounded Task.WhenAll on tarball downloads could slam our infrastructure if a workflow has a large number of unique actions at one depth. I'd be more comfortable with a conservative concurrency limit. Maybe SemaphoreSlim(2)?

@stefanpenner let's through this PR first, then revisit #4297.