[Enhanced server] fileserver_add: specific rules are nondeterministically ignored for some resources, which silently fall through to a later wildcard rule

[IchigoWalker]

Summary

With per-resource fileserver_add rules (22 anchored rules like "^gm-core$" declared before a final ".*" fallback), the Enhanced server assigns 20 of 22 resources to their correct fileserver, but exactly two resources ("bunker", "EventSquare") are silently assigned the wildcard's fileserver instead of their own — visible directly in /resources/list.json. The affected rules are byte-clean, correctly ordered, not duplicated; case sensitivity is ruled out (mixed-case rules like ^GuardOutpost$ match fine). Looks like rule iteration order is not the declaration order (unordered container?), so ".*" sometimes wins over a specific rule.

Issue type

Server

Repro rate

Always

Server build version

b106 linux

OS

No response

CPU

No response

GPU

No response

RAM

No response

Storage type

None

Connection type

None

ISP and bandwidth

No response

DxDiag

No response

Network graph

No response

Platform

Linux

OS version / distribution

Ubuntu 22.04, Docker

CPU

AMD Ryzen 9 9950X

RAM

182G

Using txAdmin?

No

Hosting provider

Other GSP

Machine type

Dedicated

/perf endpoint output

No response

DDoS protection

CosmicGuard

ulimit -n value (Linux only)

1024

Docker Compose file (Docker only)

Available on request

Steps to Reproduce

1. Enhanced server with ~22 started resources. In server.cfg declare one anchored rule per resource, then a wildcard fallback LAST:
   fileserver_add "^<resource_name>$" "http://files.example.com/" (x22)
   fileserver_add ".*" "http://files.example.com/"
2. Start the server.
3. Request http://:/resources/list.json and compare each resource's "fileServer" field against its declared rule.

Result in our setup: 20/22 resources get their own rule's URL (hash matches their rule exactly), while "bunker" and "CursedSquare" get the wildcard's URL. 100% reproducible across restarts and container recreations with the same rule set. I can share the full generated server.cfg and the exact resource list privately.

Expected Behavior

First-match-wins in declaration order: a resource whose anchored rule ("^bunker$") is declared before the wildcard should always be assigned that rule's fileserver.

Actual Behavior

Exactly two resources are assigned the wildcard rule's fileserver despite their specific rules being present, well-formed, and declared earlier. Which resources are affected looks arbitrary (one all-lowercase name, one mixed-case; declaration positions 5 and 11 of 22) but is stable for a given rule set.

Evidence

server.cfg excerpt (generated; full fileserver block, declaration order):

fileserver_add "^PolyZone$" "http://files.example.com/v-0aa8161b1dec01bc"
fileserver_add "^gm-core$" "http://files.example.com/v-8370481d03c05446"
fileserver_add "^gm-loading-screen$" "http://files.example.com/v-ebf0674905ee1d5a"
fileserver_add "^gm-sounds$" "http://files.example.com/v-8ef027956a7ee5d7"
fileserver_add "^EventSquare$" "http://files.example.com/v-21c2af7832ad2127"      <- present, IGNORED
fileserver_add "^GuardOutpost$" "http://files.example.com/v-51ca460543ff025a"
fileserver_add "^ServiceZone_connect_Annex$" "http://files.example.com/v-9ec750b3ebf42452"
fileserver_add "^Utility_Zone$" "http://files.example.com/v-75403fa2b35acedd"
fileserver_add "^TheBrokenBridge$" "http://files.example.com/v-28a1b86267780585"
fileserver_add "^dock$" "http://files.example.com/v-758c78a13188940a"
fileserver_add "^bunker$" "http://files.example.com/v-dd94aa9ec52366e7"           <- present, IGNORED
fileserver_add "^bunker_room$" "http://files.example.com/v-213ec2624cf27e2c"
fileserver_add "^start_room$" "http://files.example.com/v-d95b89c3df30ca8f"
fileserver_add "^gm-minimap$" "http://files.example.com/v-56d74c77a88a0000"
fileserver_add "^gm_carwreck$" "http://files.example.com/v-8a2c2d0b8a1a4085"
fileserver_add "^bob74_ipl$" "http://files.example.com/v-a69d5e5e0873cab6"
fileserver_add "^lootcrate$" "http://files.example.com/v-8b5afcf9b1b8b906"
fileserver_add "^navmeshes$" "http://files.example.com/v-27cc4c3510a09587"
fileserver_add "^props_new$" "http://files.example.com/v-78e271d6566d7a37"
fileserver_add "^required_ipls$" "http://files.example.com/v-7602fc0935b68306"
fileserver_add "^scaleforms$" "http://files.example.com/v-50dcd557c794c8fe"
fileserver_add "^weather$" "http://files.example.com/v-c751f36c4170f903"
fileserver_add ".*" "http://files.example.com/v-g784f68666bb4e434"

/resources/list.json assignment (sorted by prefix; every correct assignment's hash equals its rule's hash EXACTLY):

v-0aa8161b1dec01bc   PolyZone
v-213ec2624cf27e2c   bunker_room
v-27cc4c3510a09587   navmeshes
v-28a1b86267780585   TheBrokenBridge
v-50dcd557c794c8fe   scaleforms
v-51ca460543ff025a   GuardOutpost
v-56d74c77a88a0000   gm-minimap
v-75403fa2b35acedd   Utility_Zone
v-758c78a13188940a   dock
v-7602fc0935b68306   required_ipls
v-78e271d6566d7a37   props_new
v-8370481d03c05446   gm-core
v-8a2c2d0b8a1a4085   gm_carwreck
v-8b5afcf9b1b8b906   lootcrate
v-8ef027956a7ee5d7   gm-sounds
v-9ec750b3ebf42452   ServiceZone_connect_Annex
v-a69d5e5e0873cab6   bob74_ipl
v-c751f36c4170f903   weather
v-d95b89c3df30ca8f   start_room
v-ebf0674905ee1d5a   gm-loading-screen
v-g784f68666bb4e434  bunker          <- WILDCARD (wrong)
v-g784f68666bb4e434  EventSquare     <- WILDCARD (wrong)

cat -A over the affected rules (no hidden characters — plain LF endings):

fileserver_add "^EventSquare$" "http://files.example.com/v-21c2af7832ad2127"$
fileserver_add "^bunker$" "http://files.example.com/v-dd94aa9ec52366e7"$
fileserver_add "^bunker_room$" "http://files.example.com/v-213ec2624cf27e2c"$

Additional Context

Resource names in this report are pseudonymized (case patterns and declaration order preserved exactly); the real generated server.cfg and resource list are available privately on request.

[wolfram-cfx]

Thanks, we are looking into this.

[stelianclaudiu92-commits]

Great comment. UP!

[Gogsi]

A fix for this bug has been implemented and is available in the August 4 patch. Please try again and let us know if the issue persists. Thanks for your help!