Conversation
|
chainlist/tests/check-duplicate-keys.js Lines 153 to 205 in c7c113b |
|
you are right, thanks. the line scan only saw urls on their own line at fixed indentation, so every single-line e7f0890 drops the line parsing for this check. duplicate keys have to be read from source because an import keeps only the last one, but arrays survive an import intact, so it now imports rechecked with the complete count: this branch has no duplicates, and neither does a trial merge with current main (2,972 urls). main on its own still has the 21 this pr removes. i also injected a duplicate into a one-line array (chain 1975, |
|
Validation failed for chain files. Please check the workflow logs for details. Error message: |
|
On the red Short version. The workflow computes its changed-file list as This PR's diff is Replaying the validator over the registry, 8 of 511 files fail it today, so any PR touching The duplicate-key test itself is unchanged since |
…d one-line arrays (2,774 of 2,982 urls)
e7f0890 to
9c2ea73
Compare
|
Rebased onto current main; Nothing in the diff changed: still (Fixing a previous version of this comment that lost two code spans to shell quoting.) |
Fixes #3067
tests/check-duplicate-keys.jscatches duplicatechainIdkeys, but the rpcs are an array and arrays keep every entry, so the same url listed twice inside one chain was invisible to it. there were 21 across 18 chains.removes all 21 and adds
checkDuplicateRpcUrls()in the same source-parsing style as the existing checks. it normalises trailing slashes and case, so thehttps://erpc.xinfin.network/https://erpc.xinfin.network/pair on chain 50 is caught too.where the same url appeared once as a bare string and once as an object, the object is kept; it carries
trackingandtrackingDetails, so nothing is lost. that covers 8 of them (13371, 16600, 20230825, 3501, 50001, 7869, 11297108099). the rest were identical entries and the first is kept.one needs your call. chain 534351 had
https://rpc.ankr.com/scroll_sepolia_testnettwice with the sameprivacyStatement.ankrbut disagreeing ontracking, one"limited", one"none". i kept the first ("limited") because it is the conservative claim, not because i think it is right: ankr is inconsistent across the whole file (50 entries"none", 16"limited", 3"yes"), so there is no convention to follow. happy to flip it if"none"is correct, and the wider ankr inconsistency is probably worth its own pass.and with a duplicate put back: