Compiler-generated repo-memory push concurrency is broader than the actual write surface

[j-srodka]

Summary

When repo memory is enabled, multiple compiled workflows may push to different memory/* branches. The compiler still emits repo-memory push jobs that share a single repository-wide Actions concurrency group. That group is broader than the real per-branch git write-conflict surface.

Analysis

Under load, queued pushes can be serialized unnecessarily or cancelled (for example when a newer run supersedes another in the same group). The overall workflow conclusion can become non-success even when the primary agent job already completed useful work. Downstream automation that keys off workflow_run.conclusion == success may then skip incorrectly.

This is compiler-generated behavior with repo-wide effects—not something authors can fully correct by "designing workflows differently" while still using repo memory across multiple definitions.

Several unrelated workflow types, different memory/* targets, identical concurrency key derived only from github.repository; tail memory push cancelled or failed; workflow marked failed/cancelled while agent job succeeded.

Implementation plan

1. Tighten the default concurrency key so it reflects the actual collision domain—at minimum include memory branch and/or workflow identity (exact formula is a product decision).
2. Alternatively, provide a supported, source-level override for that concurrency group that survives recompile, so operators can align locking with their real contention model without hand-editing lockfiles each time.
3. Document how tail job outcomes relate to workflow conclusion when memory push is best-effort vs required, so consumers can gate automation appropriately.

Expected outcome

Memory pushes only contend when they target the same mutable surface, and workflow conclusions better match whether primary agent work succeeded.