jamulusserver/setDirectory silently substitutes any_genre_1 for an unrecognised directoryType and replies ok

🤖 AI: jamulusserver/setDirectory accepts any string as directoryType and replies "ok". Unrecognised values are silently mapped to any_genre_1, the public default.

DeserializeDirectoryType() returns AT_DEFAULT when the lookup misses, and sumStringToDirectoryType is an unordered_map keyed on std::string, so matching is byte-exact: case-sensitive and not trimmed.

Measured on loopback with *.jamulus.app redirected to 127.0.0.1 in /etc/hosts, so no probe reached a real directory. Each row: set, then read back with getServerProfile, one request per fresh connection.

Two consequences.

A typo moves a running server off its chosen genre. Set genre_jazz, then send GENRE_JAZZ. The reply is "ok" and the server is now registered with any_genre_1.

The custom guard cannot fire for the inputs it exists to catch. setDirectory already rejects custom supplied without a directoryAddress, but that check tests the deserialized enum rather than the input string — so "CUSTOM" becomes AT_DEFAULT before the check runs. An operator asking for their own directory is registered with the public one, their directoryAddress stored and ignored, and the reply is "ok".

The matrix above was measured against main @ 97799184. I re-checked today: DeserializeDirectoryType() is byte-identical in main and in r3_12_4, so this is present unchanged in release/3_12.

I hit this in practice rather than only in testing — unregistering a server via {"directoryType":"none"} is one keystroke away from publishing it to the busiest directory on the network, with a success reply either way.

I have a patch that returns -32602 for an unrecognised value, echoing it and listing the accepted set, and leaves the directory setting unchanged. It follows jamulusclient/setSkillLevel, which already rejects unrecognised enum strings this way. A/B against baseline across 24 cases of the server RPC surface: 22 identical, 2 intended differences, 0 unintended.

Before opening anything, one decision that is yours rather than mine.

Rejecting is a behaviour change on an API released in 3.12.0. A script sending a bad value today gets "ok"; afterwards it gets an error. My reading is that this is the point, since the current reply reports a success that did not happen — but it is a break, so:

• reject on main only and leave release/3_12 as is,
• reject on both,
• or an alternative you prefer, such as keeping the fallback and reporting the substitution in the result.

Happy to open a PR once you've said which.

🤖 This message was written by AI and reviewed by @mcfnord.

エントリポイント jamulusserver/setDirectory から開始し、DeserializeDirectoryType() と sumStringToDirectoryType を調べてください。検証動作を jamulusclient/setSkillLevel と比較してください。報告されている24ケースのサーバー RPC 比較をテストの基準として使用し、無効な値がディレクトリ設定を変更せずにエラーを返すようになった時点で、main と release/3_12 のどちらにするかというメンテナーの判断が完了したものとみなしてください。