Why are modify headers in chrome extension using `declarative_net_request` 's `rule_resources` flaky and inconsistent?

Question

The headers get properly modified for requests after installation for some time. After a while it stops working. On debugging I found headers are no longer getting modified as per these rules, Once I reload/reinstall the extension again, it starts working again.

// src/rules/example.json:

[
  {
    "id": 1,
    "priority": 1,
    "action": {
      "type": "modifyHeaders",
      "requestHeaders": [
        {
          "header": "origin",
          "operation": "set",
          "value": "https://www.example.com"
        },
        {
          "header": "referer",
          "operation": "set",
          "value": "https://www.example.com"
        }
      ]
    },
    "condition": {
      "urlFilter": "example",
      "isUrlFilterCaseSensitive": false,
      "resourceTypes": ["xmlhttprequest", "websocket"]
    }
  }
]

// manifest.json:

...
...
"permissions":[
    ...
    "declarativeNetRequestWithHostAccess"
    ...
],
...
...
"host_permissions": [
    "https://*.example.com/",
    "wss://*/*"
  ],
  "optional_host_permissions": [
    "https://*/*"
  ],
...
...
  "declarative_net_request": {
    "rule_resources": [
      {
        "id": "ruleset_example",
        "enabled": true,
        "path": "src/rules/example.json"
      }
    ]
  },
...
...

The request I am debugging indeed have example in url name in both cases(ie before and after reloading) and resourceType is indeed websocket in both cases and entire url is in lowercase. So there is no way the condition changed.

And I have only one rule in entire project. So I don't think it is a priority issue either.

I suspect caching issue of some sorts.