CACHE-13504: remove gate from request cf

[tewaro]

Supersedes #6623

[ask-bonk]

I'm Bonk, and I've done a quick review of your PR.

This PR removes the workerdExperimental gate from the cf.cacheControl feature, making cacheControl synthesis, mutual-exclusion validation, and cf-blob dual-writes unconditional for all workers.

Issues (ranked by severity)

1. [High] Ungated backward-incompatible change -- new TypeError for previously-accepted inputs. The RequestInitializerDict::validate changes introduce TypeError throws for workers that pass cf.cacheControl together with cf.cacheTtl or the cache request option. Previously (without the --experimental flag), these combinations were silently accepted. Any existing worker that happens to set cf.cacheControl alongside cf.cacheTtl will now break at Request construction time. Per the project's own workerdExperimental documentation in compatibility-date.capnp (lines 266-269): "Don't use this for backwards-incompatible changes; give them their own flag." And per AGENTS.md: "Strong backwards compatibility commitment -- features cannot be removed or changed once deployed." This validation should be gated behind a dedicated compat flag (e.g., cf_cache_control_validation) with a future enable date, rather than being unconditionally enabled.

2. [Medium] Ungated wire-format change -- new cacheControl field in serialized cf blob for all workers. Removing the gate means every worker using cacheTtl or the cache request option now gets an additional cacheControl field in the serialized cf JSON blob (the dual-write path). While the old fields are preserved, this changes the downstream wire format for existing workers that never opted into this behavior. If downstream infrastructure is already consuming cacheControl (as suggested by the superseded PR requiring a specific pingora-origin version), unconditionally enabling this for all workers without a staged rollout via compat flag could cause issues for workers on older infrastructure versions.

Both of these changes warrant their own compat flag per the project's conventions. The workerdExperimental flag was the correct development-time gate, but the path from experimental to GA should go through a dedicated compat flag, not straight to unconditional.

[ask-bonk]

Review posted successfully on PR #6630. Here's a summary of my findings:

Two issues flagged:

1. [High] Ungated backward-incompatible change: The RequestInitializerDict::validate changes now throw TypeError for input combinations (cf.cacheControl + cf.cacheTtl, or cf.cacheControl + cache option) that previously succeeded silently. This violates the project's own backward compatibility guidelines and the workerdExperimental documentation which explicitly says "Don't use this for backwards-incompatible changes; give them their own flag."

2. [Medium] Ungated wire-format change: Every worker using cacheTtl or the cache request option now gets an additional cacheControl field in the serialized cf JSON blob. While the old fields are preserved (dual-write), this changes downstream behavior for all existing workers without a staged rollout.

Both changes should go through a dedicated compat flag rather than being unconditionally enabled.

github run