🚀 Feature Request: Cache network failures when fetching DID document or FAIR metadata #420
Description
Describe the problem that needs this feature
WordPress core suffers from a problem whereby HTTP API failures for update checks aren't cached. If api.wordpress.org is down when your site's update transients expire, then every wp-admin page request will fire off one or more HTTP API requests to api.wordpress.org in an attempt to fetch update data. This has two effects:
- wp-admin page load speeds will slow to a crawl while the HTTP API requests wait to timeout. The timeouts in core are anywhere from 3 seconds upward (the timeout for plugin update checks is dynamic depending on the number of plugins being checked).
- api.wordpress.org will experience a stampede of requests while it's down, because none of its "clients" are caching the failures.
The same effect can be seen for requests made directly by FAIR Connect to fetch DID documents from plc.directory and to fetch FAIR metadata from service endpoints defined in the DIDs.
This problem is arguably worse with FAIR Connect active because of the distributed nature of FAIR service endpoints. A site using FAIR Connect will, by its nature, depend on a larger number of separate hosts than a vanilla WordPress site, thus increasing the likelihood of any of them having availability issues.
Recently, the FAIR service endpoint for the Pods plugin was down for a few days. Using the Query Monitor plugin I was able to see FAIR attempting to fetch this endpoint on every wp-admin page load, which exhibited both the effects listed above.
Describe the solution you'd like
FAIR Connect can and should mitigate this problem by caching HTTP API failures when fetching DID documents from plc.directory and FAIR metadata from service endpoints. The cache expiry time is up for debate but I think an hour is a good balance between caching failures for too long (which is unnecessary) and not long enough (which might not mitigate the effects enough).