Repository navigation
[plan] Add memory restore support to custom jobs: via a restore-memory step injection #43946
Description
Objective
Allow custom jobs: defined in workflow frontmatter to declare that they need read access to memory stores (cache-memory, repo-memory, comment-memory), so a deterministic orchestrator job can compute a dispatch list from memory without the agent job.
Context
Issue #43924 describes the ideal OrchestratorOps pattern: a scheduled deterministic job reads cache-memory (e.g., { "<pr>": "<last-reviewed-sha>" }), diffs against current state, builds a dispatch list, then fan-outs. Today this is impossible because memory stores are exclusively restored in the agent job.
Custom jobs: are defined in the jobs: frontmatter section and compiled by pkg/workflow/compiler_custom_jobs.go. They currently support setup-steps, steps, pre-steps, and needs: — but no mechanism to inject memory restore steps.
Implementation Plan
Implementation Plan
Files to Modify
pkg/workflow/compiler_custom_jobs.go— detect a new optionalmemory:orrestore-memory:field on custom job configs, and inject the corresponding restore steps before the usersteps:pkg/workflow/cache.go— refactor/extract restore-only variants ofgenerateCacheMemoryStepsandgenerateRepoMemoryStepsthat do not emit write-back steps, for reuse in custom jobs and pre-activation- Schema/docs — update the custom jobs schema if applicable
- Tests — add a test verifying that a custom job with
memory: cache-memorygets the restore step injected
Approach
- Design the frontmatter shape. A minimal option: custom jobs support a
restore-memory: true(or a list of store names) field that opts in to memory restore injection. Alternatively, auto-inject when memory is configured and the job does not explicitly opt out. - In
buildCustomJob(incompiler_custom_jobs.go), check for the memory-restore opt-in and prepend memory restore steps before the job's usersteps:. - Extract a read-only restore step generator from
generateCacheMemorySteps/generateRepoMemorySteps(these currently also emit git integrity setup steps that are agent-specific). The extracted version should only emit theactions/cacherestore step and directory creation. - For
comment-memory, emit the "Prepare comment memory files" step before user steps (token must be available — ensure the custom job hasgithub-tokenaccess). - Add a compiler validation error if a custom job tries to write to memory (guard against misuse).
Notes
- Memory restore in custom jobs is read-only — write-back/commit steps must not be injected. Only the agent job writes back to memory.
- Related to issue Allow frontmatter to augment the needs list of any compiler-generated job #43918 (needs-wiring for compiler-generated jobs): if a
restore-memoryjob is introduced as a shared job in the future, custom jobs couldneeds:it instead of each injecting their own restore steps.
Acceptance Criteria
- A custom
jobs:entry can opt into readingcache-memorycontent at its documented path - Same for
repo-memoryandcomment-memory - No write-back/commit steps are emitted for memory in custom jobs
- Compiler validation rejects custom jobs that attempt to write to memory
- Existing custom jobs tests continue to pass (
make test) - New test covers custom job with memory restore
-
make recompilepasses
Generated by 📋 Plan Command · 79.6 AIC · ⌖ 11.7 AIC · ⊞ 4.7K · ◷
Comment /plan to run again
- expires on Jul 8, 2026, 10:39 PM UTC-08:00
Activity
github-actions commentedon Jul 7, 2026
🍪 Issue Monster selected this for Copilot
I have identified this issue as a good candidate for automated resolution and requested assignment to the Copilot coding agent.
If assignment succeeds, the Copilot coding agent will analyze the issue and create a pull request with the fix.
Om nom nom! 🍪
Add restore-memory support to custom jobs via step injection