Podcast Player: keep rendering when the feed is slow or unreachable - #51212
Conversation
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! Jetpack plugin: The Jetpack plugin has different release cadences depending on the platform:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
Code Coverage SummaryCoverage changed in 1 file.
Full summary · PHP report · JS report If appropriate, add one of these labels to override the failing coverage check:
Covered by non-unit tests
|
Cache the error itself, never the fallback, so the editor still refetches. Treat an empty feed as authoritative rather than serving stale episodes.
Only remember a failure when stale episodes exist to cover it, so a cold start retries instead of sitting empty. Drop the stored episodes when the feed reports itself empty, and move the error window off the five-minute edge cache TTL.
Let the editor's endpoint ask for errors directly, so other REST renderers still get the fallback. Keep stored episodes when a feed reports itself empty, and add a filter to tune or disable the fallback.
Remember failures when the fallback is switched off, so disabling stale output doesn't also disable negative caching. Seed the fallback from a cache entry that predates it, so an upgrade doesn't leave feeds uncovered until they next refresh.
Nothing asked for it, and the only behaviour it bought was an empty block during outages instead of stale episodes, since errors already render blank for anyone without edit_posts.
Proposed changes
Podcast feeds go down sometimes. When that happened, the Podcast Player block showed nothing at all — even if the same feed had loaded fine minutes earlier.
Does this pull request change what data or activity we track or use?
No. Feed responses were already cached; this keeps one extra copy of the same data as a fallback.
Testing instructions
wp transient delete --all.trunkthe block renders empty here.