Limit Fastly cache TTL for error responses (status >= 400) to 30s

[benhalpern]

Goal

Limit the Fastly cache TTL for error status responses (HTTP status >= 400) to 30 seconds.

Problem Context

When a request to a custom domain (or standard page) fails or is misconfigured, Fastly caches the resulting 404 response page (or fallback redirects) using its default service TTL (which is configured for up to 30 days) when the response lacks explicit Cache-Control/Surrogate-Control headers. This causes pages (like newly-published articles) to render as 404 to users for an extended period, even after they have been published or the domain configuration is corrected.

Proposed Changes

This PR modifies the block in the Fastly VCL snippet stale_while_revalidate_controls.vcl to:

• Detect error responses (beresp.status >= 400).
• Set beresp.ttl = 30s (caching them for at most 30 seconds to absorb traffic spikes without keeping errors stuck indefinitely).
• Set beresp.cacheable = true so the error responses are explicitly cacheable for that duration.

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}

[github-actions]

Thank you for opening this PR! We appreciate you!

For all pull requests coming from third-party forks we will need to
review the PR before we can process it through our CI pipelines.

A Forem Team member will review this contribution and get back to
you as soon as possible!

[Copilot]

Pull request overview

This PR updates Forem’s Fastly VCL to ensure HTTP error responses (status >= 400) are only cached for a short duration (30 seconds), preventing long-lived cached 404s/other errors (e.g., after publishing or correcting a custom domain configuration).

Changes:

• Add a beresp.status >= 400 condition in the stale_while_revalidate_controls.vcl snippet.
• Set beresp.ttl = 30s for error responses and explicitly mark them cacheable.