Ruleset cache is not invalidated when changing format (json <-> binary)

[Danstiv]

Operating system

Windows

System version

Windows 11 25H2 (AMD64) build 26200.8246

Installation type

Original sing-box Command Line

If you are using a graphical client, please provide the version of the client.

No response

Version

sing-box version 1.13.8  Environment: go1.25.8 windows/amd64 Tags: with_gvisor,with_quic,with_dhcp,with_wireguard,with_utls,with_acme,with_clash_api,with_tailscale,with_ccm,with_ocm,with_naive_outbound,with_purego,badlinkname,tfogo_checklinkname0 Revision: d5adb54bc6c6b2c21ab6f748276c4ec62d9bb650 CGO: disabled

Description

When changing the rule set type (json -> binary or binary -> json), it is not invalidated in the cache, and sing-box cannot start.

Reproduction

1. Create config.json and rule_set.json (content provided below).
2. Run sing-box rule-set compile rule_set.json.
3. Start the python web server in directory that contains rule_set.json and rule_set.srs files python -m http.server.
4. Start sing-box with the provided config.
5. Ensure that sing-box is started and cache file was created.
6. Stop sing-box.
7. Change rule set url ending from .json to .srs, do not change the tag.
8. Run sing-box.

Expected behavior

Sing box should ignore / invalidate cache entry with the old format and refetch ruleset from the server.

Actual behavior

Following error was logged: FATAL[0000] start service: initialize rule-set[0]: restore cached rule-set: invalid sing-box rule-set file

Files

config.json

{
  "route": {"rule_set": [{"type": "remote", "tag": "rule_set1", "url": "http://127.0.0.1:8000/rule_set.json"}]},
  "experimental": {"cache_file": {"enabled": true}}
}

rule_set.json

{
  "version": 3
}

Logs

Supporter

• I am a sponsor

Integrity requirements

• I confirm that I have read the documentation, understand the meaning of all the configuration items I wrote, and did not pile up seemingly useful options or default values.
• I confirm that I have provided the server and client configuration files and process that can be reproduced locally, instead of a complicated client configuration file that has been stripped of sensitive data.
• I confirm that I have provided the simplest configuration that can be used to reproduce the error I reported, instead of depending on remote servers, TUN, graphical interface clients, or other closed-source software.
• I confirm that I have provided the complete configuration files and logs, rather than just providing parts I think are useful out of confidence in my own intelligence.