Automattic / Automattic/wp-codebox

Cache or retry WordPress release metadata startup asset resolution

Open
#968 0 comments 0 reactions 0 assignees View on GitHub
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.