Automattic / Automattic/wp-codebox
Cache or retry WordPress release metadata startup asset resolution
- Dominant language
- TypeScript
- Stars
- 16
- Forks
- 4
- Avg merge
- 59m
- Merged PRs (30d)
- 131
Description
## Problem
Several Lab WP Codebox runs failed before the agent task could execute because Playground startup could not fetch WordPress release metadata:
`Unable to resolve Playground startup asset wordpress-release-metadata for WordPress latest from https://api.wordpress.org/core/version-check/1.7/?channel=beta: fetch failed`
This showed up during WPSG Lab pilots while switching provider paths. It is independent of the model/provider choice and turns transient network/metadata fetch failures into full task failures.
## Expected
WP Codebox should make this startup path more resilient for Lab cooking:
- cache WordPress release metadata/startup assets between runs when safe,
- retry transient fetch failures with useful backoff,
- optionally allow the runner/plan to pin a known WordPress version or use a local cached release asset,
- surface a concise diagnostic that distinguishes infrastructure fetch failure from agent/model failure.
## Evidence From Today
Observed in WPSG pilot runs including:
- `site-generation-loop-20260615c`
- `site-generation-loop-20260615e`
Representative diagnostic:
`agent_runtime.workload: Unable to resolve Playground startup asset wordpress-release-metadata for WordPress latest from https://api.wordpress.org/core/version-check/1.7/?channel=beta: fetch failed`
Artifacts referenced by Homeboy included WP Codebox artifact directories such as:
- `/home/chubes/Developer/.tmp/homeboy-wp-codebox-artifacts-C7Pk4Q`
- `/home/chubes/Developer/.tmp/homeboy-wp-codebox-artifacts-tzyP4h`
## Why This Matters
For Lab cooking, startup metadata fetch should not be a frequent blocker. It also obscures whether the actual provider/model path is working because the failure happens before useful agent execution evidence exists.
## Acceptance Criteria
- Transient `api.wordpress.org` metadata fetch failures are retried or served from a safe cache.
- The final diagnostic includes whether the failure was cache miss, network fetch failure, or invalid metadata.
- A plan/runtime option exists to pin or reuse a cached WordPress release for repeatable Lab runs.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.