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.

[ericsciple]

Can you add a feature flag? If messy, prefer duplicating the methods with suffix _Legacy vs _New

Runner feature flags are sent from the server in the job message as variables. In the runner code, you read them via context.Global.Variables.GetBoolean(...).

Step 1: Define the flag constant in Constants.Runner.Features:

public static readonly string BatchActionResolution = "actions_batch_action_resolution";

Step 2: Check the flag at the top of your new codepath, falling back to the old behavior when it's off:

var batchActionResolution = executionContext.Global.Variables.GetBoolean(Constants.Runner.Features.BatchActionResolution) ?? false
    || StringUtil.ConvertToBoolean(Environment.GetEnvironmentVariable("ACTIONS_BATCH_ACTION_RESOLUTION"));

if (batchActionResolution)
{
    // new batched/deduped resolution
}
else
{
    // original resolution logic
}

Step 3: Env var fallback for local testing. The || Environment.GetEnvironmentVariable(...) pattern lets you test locally with a self-hosted runner by setting an env var, without needing the server to send the flag. This is an existing pattern — see ExecutionContext.cs L1422-1426 for an example:

var allowServiceContainerCommand = (context.Global.Variables.GetBoolean(Constants.Runner.Features.ServiceContainerCommand) ?? false)
    || StringUtil.ConvertToBoolean(Environment.GetEnvironmentVariable("ACTIONS_SERVICE_CONTAINER_COMMAND"));

if ((context.Global.Variables.GetBoolean(Constants.Runner.Features.CompareWorkflowParser) ?? false)
    || StringUtil.ConvertToBoolean(Environment.GetEnvironmentVariable("ACTIONS_RUNNER_COMPARE_WORKFLOW_PARSER")))

[stefanpenner]

onit.

[stefanpenner]

updated, LMK

[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]

This test’s name/comments claim next-level actions are “pre-downloaded … BEFORE recursion”, but the assertion only checks that depth-1 watermarks exist by the time the 3rd resolve occurs. That condition would also hold if depth-1 downloads happen inside the depth-1 recursive call (i.e., it doesn’t actually verify pre-download-before-recursion behavior).

Consider tightening the test to assert the timing more directly (e.g., detect whether downloads occur during recursion vs before it), or rename the test/comments to reflect what’s actually being validated.

[Copilot]

resolvedDownloadInfos uses StringComparer.OrdinalIgnoreCase, but the lookup key is ${owner/repo}@${ref}. Git refs are case-sensitive, so this comparer can incorrectly treat repo@main and repo@Main (or tags differing only by case) as the same action and reuse the wrong ActionDownloadInfo/archive.

Consider changing the cache key so only the owner/repo portion is case-insensitive (to address #3731), while keeping ref case-sensitive (e.g., a structured key or normalized owner/repo + original ref).

[Copilot]

With the new cross-depth cache, the same ActionDownloadInfo can be reused for later Pipelines.ActionSteps whose RepositoryPathReference.Name differs only by case. DownloadRepositoryActionAsync downloads to a directory based on downloadInfo.NameWithOwner, but PrepareRepositoryActionAsync (and later LoadAction) locate action.yml using repositoryReference.Name. On case-sensitive filesystems this can make the manifest lookup fail if the cached downloadInfo.NameWithOwner casing doesn’t match the step’s repositoryReference.Name.

To make case-dedup safe, ensure a single canonical directory name is used consistently for both download and manifest lookup (e.g., normalize repositoryReference.Name after resolution to the resolved canonical name, or pass the resolved name into the path computations).