fix: bound blocking editor-dropdown API calls on the metabox render path

[galbus]

Problem

Client::cached_get() powers the classic-editor metabox's dropdowns. On every post.php / post-new.php render, Metabox::render_meta_box_content() triggers up to 3 sequential blocking API calls — get_summarization_settings_templates(), get_video_settings_templates(), get_video_settings().

Two problems compounded:

• Failures were never cached. cached_get() only stored a transient for a 2xx response with an array body. WP_Error (timeout/DNS), 5xx, and non-JSON responses fell through, so the identical 3-call stall repeated on every edit-screen load for the duration of an incident.
• Render path inherited the 30s write timeout. build_args() hard-coded timeout => 30, so each call could block up to 30s (~90s per render).

A 401 self-heals (call_api() clears beyondwords_valid_api_connection, which ungates the metabox in Plugin::init), but a network blackhole / DNS failure / 5xx does not clear that flag — so the metabox keeps rendering and keeps re-issuing the requests, tying up PHP-FPM workers and making wp-admin editing unusable while the API is degraded.

Fix

All changes are in src/api/class-client.php:

1. Negative-cache failures. cached_get() now writes set_transient($key, [], CACHE_TTL_ON_ERROR) (2 min) for any WP_Error / non-2xx / non-JSON response, using an empty-array sentinel (never false, so get_transient's hit/miss check stays unambiguous). An outage now costs one probe per 2 min instead of one per render. Successful responses keep the 15-min CACHE_TTL.
2. Short render-path timeout. Added a $timeout param threaded cached_get() → call_api() → build_args(). Render-path GETs pass RENDER_REQUEST_TIMEOUT (3s, per VIP / vip_safe_wp_remote_get guidance); write-path calls keep WRITE_REQUEST_TIMEOUT (30s). Routing through call_api() preserves the existing 401 self-heal.

Worst case during an outage drops from ~90s-per-render-forever to a single ~9s render, then cached for 2 min.

Reviewer notes

• No new phpcs:ignore. The 3s render-path timeout is VIP-compliant on its own. The pre-existing ignore remains only for the legitimate 30s write-path timeout (with a clarified comment explaining the trade-off).
• Deliberately skipped the optional has_api_creds() short-circuit: it would break the tested contract that a no-creds get_languages()/get_voices() returns the API's 401 message array, and it's largely redundant — the metabox is already gated on has_valid_api_connection(), and the negative-cache + short-timeout already bound the no-creds cost to one 3s probe per 2 min.
• Out of scope: the 30s write-path timeout still trips the VIP sniff and relies on the existing ignore. That's a deliberate save-reliability trade-off, not part of this defect.

Testing

• phpcs (full WordPress-VIP-Go scan): clean, exit 0.
• ClientTest — 41 tests / 136 assertions pass. Replaced failed_responses_are_not_cached with failed_responses_are_negative_cached (2nd call served from cache) and added render_path_gets_use_a_short_timeout (render GET ≤3s, write path =30s).
• SettingsFieldsTest (exercises the metabox render path) — 22 tests / 90 assertions pass.
• Did not run the full Cypress suite.

🤖 Generated with Claude Code

[github-actions]

✅ WordPress Plugin Check Report

✅ Status: Passed

📊 Report

All checks passed! No errors or warnings found.

---

🤖 Generated by WordPress Plugin Check Action • Learn more about Plugin Check