Proposal type
Other
Affected scope (files/folders/chains)
listings/all-networks/.csv, listings/specific-networks//*.csv, and json-tools/tools/csv_to_json.py. Global.
Motivation / problem statement
The converter already prevents the same canonical !offer: + chain pair from appearing once in all-networks and once in a specific-network file. It does not reject the same pair twice inside one listing scope when the two rows use different listing slugs.
That leaves a logical-identity gap: rule_slug_unique sees two distinct row slugs, while validate_no_offer_reference_conflicts() silently overwrites one row in its (offer_slug, chain) dictionary before checking cross-scope conflicts.
Minimal reproduction:
network_entities = [
{"slug": "foo-a", "offer": "!offer:foo", "chain": "mainnet"},
{"slug": "foo-b", "offer": "!offer:foo", "chain": "mainnet"},
]
validate_no_offer_reference_conflicts(
"apis",
"example-network",
network_entities,
[],
)
This returns normally on the current implementation. Both keys are ("foo", "mainnet"), so the second assignment replaces the first. Because the row slugs differ, slug uniqueness does not catch it.
This is a validation-gap report, not a claim that current production data already contains such a duplicate. Open and closed issue searches for the same offer+chain invariant and duplicate offer references did not find an equivalent proposal.
Detailed proposal
Add explicit uniqueness validation for the normalized tuple:
(canonical offer slug, normalized chain)
within each listing scope/category before resolution/output generation.
- For every listing whose offer is !offer:, normalize chain exactly as the existing cross-scope check does.
- Track the first row for each (offer_slug, chain) tuple.
- Reject a second row with the same tuple even when its listing slug differs.
- Report category, network/scope, offer slug, chain, and both conflicting listing slugs.
- Preserve the existing all-networks-vs-specific-network check.
- Add regression tests:
- same offer+chain, different listing slugs -> reject
- same offer on two different chains -> accept
- two different offers on one chain -> accept
- existing cross-scope duplicate -> still reject
Example error:
Duplicate canonical listing in network 'example-network', category 'apis':
offer 'foo', chain 'mainnet' is referenced by both 'foo-a' and 'foo-b'.
No migration is required if the current dataset is clean.
Verification: reproduced against the current validate_no_offer_reference_conflicts() implementation at function level. No claim of a full upstream integration test or existing production duplicate.
Contact (optional)
No response
Rewards address (optional)
No response
Proposal type
Other
Affected scope (files/folders/chains)
listings/all-networks/.csv, listings/specific-networks//*.csv, and json-tools/tools/csv_to_json.py. Global.
Motivation / problem statement
The converter already prevents the same canonical !offer: + chain pair from appearing once in all-networks and once in a specific-network file. It does not reject the same pair twice inside one listing scope when the two rows use different listing slugs.
That leaves a logical-identity gap: rule_slug_unique sees two distinct row slugs, while validate_no_offer_reference_conflicts() silently overwrites one row in its (offer_slug, chain) dictionary before checking cross-scope conflicts.
Minimal reproduction:
network_entities = [
{"slug": "foo-a", "offer": "!offer:foo", "chain": "mainnet"},
{"slug": "foo-b", "offer": "!offer:foo", "chain": "mainnet"},
]
validate_no_offer_reference_conflicts(
"apis",
"example-network",
network_entities,
[],
)
This returns normally on the current implementation. Both keys are ("foo", "mainnet"), so the second assignment replaces the first. Because the row slugs differ, slug uniqueness does not catch it.
This is a validation-gap report, not a claim that current production data already contains such a duplicate. Open and closed issue searches for the same offer+chain invariant and duplicate offer references did not find an equivalent proposal.
Detailed proposal
Add explicit uniqueness validation for the normalized tuple:
(canonical offer slug, normalized chain)
within each listing scope/category before resolution/output generation.
Example error:
Duplicate canonical listing in network 'example-network', category 'apis':
offer 'foo', chain 'mainnet' is referenced by both 'foo-a' and 'foo-b'.
No migration is required if the current dataset is clean.
Verification: reproduced against the current validate_no_offer_reference_conflicts() implementation at function level. No claim of a full upstream integration test or existing production duplicate.
Contact (optional)
No response
Rewards address (optional)
No response