[BUG] Providing cache_ttl_by_status cache setting for fetch requests not respected.

[caiges]

Is there an existing issue for this?

• [X] I have searched the existing issues

What version of workers-rs are you using?

0.0.18

What version of wrangler are you using?

3.22.1

Describe the bug

I am making a fetch request with cache settings provided via cache_ttl_by_status but it seemingly does not apply to sub requests compared to the equivalent JavaScript implementation. Requests are still made to my origin far too frequently to be leveraging the provided cache configuration.

I setup two workers, one in Rust and another in JavaScript, performing the same task of fetching a request from my origin. I continuously made requests to these workers and captured the origin's logs:

let mut cache_ttl_by_status = HashMap::new();
cache_ttl_by_status.insert("200-299".to_string(), 5);
cache_ttl_by_status.insert("300-399".to_string(), 10);

let cf_properties = CfProperties {
  cache_everything: Some(true),
  cache_ttl_by_status: Some(cache_ttl_by_status),
  ..Default::default()
};

let mut request_init = RequestInit::new();
request_init.with_method(Method::Get);
request_init.with_cf_properties(cf_properties);

let request: Request = Request::new_with_init(&uri.to_string(), &request_init).unwrap();
let response = Fetch::Request(request).send().await?;

Origin logs:

172.69.64.52 - - [10/Feb/2024:21:57:32 +0000] "GET / HTTP/1.1" 304"
172.69.64.52 - - [10/Feb/2024:21:57:33 +0000] "GET / HTTP/1.1" 304"
172.69.64.52 - - [10/Feb/2024:21:57:34 +0000] "GET / HTTP/1.1" 304"
172.69.64.52 - - [10/Feb/2024:21:57:35 +0000] "GET / HTTP/1.1" 304"
172.69.64.52 - - [10/Feb/2024:21:57:36 +0000] "GET / HTTP/1.1" 304"
172.69.64.52 - - [10/Feb/2024:21:57:37 +0000] "GET / HTTP/1.1" 304"
172.69.64.52 - - [10/Feb/2024:21:57:38 +0000] "GET / HTTP/1.1" 304"

Compared with the JavaScript implementation:

const originResponse = await fetch(url, {
  cf: {
    cacheEverything: true,
    cacheTtlByStatus: {
      '200-299': 5,
      '300-399': 10,
    },
  }
});

Origin logs:

172.69.64.52 - - [10/Feb/2024:22:08:09 +0000] "GET / HTTP/1.1" 304"
172.69.64.52 - - [10/Feb/2024:22:08:20 +0000] "GET / HTTP/1.1" 304"
172.69.64.52 - - [10/Feb/2024:22:08:31 +0000] "GET / HTTP/1.1" 304"
172.69.64.52 - - [10/Feb/2024:22:08:42 +0000] "GET / HTTP/1.1" 304"
172.69.64.52 - - [10/Feb/2024:22:08:53 +0000] "GET / HTTP/1.1" 304"
172.69.64.52 - - [10/Feb/2024:22:09:04 +0000] "GET / HTTP/1.1" 304"
172.69.64.52 - - [10/Feb/2024:22:09:15 +0000] "GET / HTTP/1.1" 304"

You can see that the Rust implementation is receiving requests every second while the JavaScript implementation receives the expected request once every 10 seconds.

Upon inspecting the Rust cf properties and request types I noticed that cache_ttl_by_status was showing as an empty JS object:

cf_properties.cache_ttl_by_status: Some({"300-399": 10, "200-299": 5})

Request type:

request cf properties: Cf { inner: IncomingRequestCfProperties { obj: Object { obj: JsValue(Object({"apps":true,"cacheEverything":true,"cacheKey":"","cacheTtl":0,"cacheTtlByStatus":{},"minify":{"__wbg_ptr":1455240},"mirage":true,"polish":"off","resolveOverride":"","scrapeShield":true})) } } }

Looking at how the TTL status map is serialized it's using serde_wasm_bindgen::to_value(&ttl_status_map).unwrap_or_default() which with a HashMap will convert to a JavaScript Map and not a plain JavaScript object like it will with JsValue::from_serde(&ttl_status_map). I also tried a JavaScript implementation using a Map for TTLs that appeared to be totally ignored -- I'm not certain what's happening on the runtime side with these properties but the behavior I observed was enough to warrant opening an issue.

Steps To Reproduce

1. Set cache_ttl_by_status cf properties to a Hashmap of various status and cache TTLs.
2. Deploy and make constant requests to the worker.
3. Observe origin being sent requests that don't match the cache TTLs of the worker's sub request.