Summary
Forest silently ignores duplicate entries of same key in params payload like:
"params": [ [ { "/":"bafy2bzacea43254b5x6c4l22ynpjfoct5qvabbbk2abcfspfcjkiltivrlyqi", "/":"bafy2bzacea4viqyaozpfk57lnemwufryb76llxzmebxc7it2rnssqz2ljdl6a", "/":"bafy2bzaceav6j67epppz5ib55v5ty26dhkq4jinbsizq2olb3azbzxvfmc73o" } ]Note two definitions for the same key /. Which CID is the one that survives? It's serde_json specific. Forest reports no issues. This should have been a parsing or validation error; in theory it's a correct JSON but in practice it'd be nice to inform the user that it's probably not what they want.
For reference, a correct payload that should have been provided instead:
"params": [ [ { "/":"bafy2bzacea43254b5x6c4l22ynpjfoct5qvabbbk2abcfspfcjkiltivrlyqi" }, { "/":"bafy2bzacea4viqyaozpfk57lnemwufryb76llxzmebxc7it2rnssqz2ljdl6a" }, { "/":"bafy2bzaceav6j67epppz5ib55v5ty26dhkq4jinbsizq2olb3azbzxvfmc73o" } ]One thing to take into consideration is potential performance degradation; this has to be verified. A straightforward implementation would create a hashset when deserializing the map; this is clearly some overhead which might not be worth it (I'd assume most calls have correct input). Perhaps strict validation could live under some environmental variable, either opt-in or opt-out.
Completion Criteria
Additional Links & Resources
Original command with faulty params:
printf '{ "jsonrpc": "2.0", "id":1, "method": "Filecoin.ChainGetMessagesInTipset", "params": [ [ { "/":"bafy2bzacea43254b5x6c4l22ynpjfoct5qvabbbk2abcfspfcjkiltivrlyqi", "/":"bafy2bzacea4viqyaozpfk57lnemwufryb76llxzmebxc7it2rnssqz2ljdl6a", "/":"bafy2bzaceav6j67epppz5ib55v5ty26dhkq4jinbsizq2olb3azbzxvfmc73o" } ] ] }' | curl http://127.0.0.1:1234/rpc/v0 -sH "Content-Type: application/json" -d@/dev/stdin | jq '.result[].Cid."/"'Original thread: https://filecoinproject.slack.com/archives/C029LPZ5N73/p1768385012689069
Summary
Forest silently ignores duplicate entries of same key in params payload like:
Note two definitions for the same key
/. Which CID is the one that survives? It'sserde_jsonspecific. Forest reports no issues. This should have been a parsing or validation error; in theory it's a correct JSON but in practice it'd be nice to inform the user that it's probably not what they want.For reference, a correct payload that should have been provided instead:
One thing to take into consideration is potential performance degradation; this has to be verified. A straightforward implementation would create a hashset when deserializing the map; this is clearly some overhead which might not be worth it (I'd assume most calls have correct input). Perhaps strict validation could live under some environmental variable, either opt-in or opt-out.
Completion Criteria
serde_jsonalready.Additional Links & Resources
Original command with faulty params:
Original thread: https://filecoinproject.slack.com/archives/C029LPZ5N73/p1768385012689069