Found while reviewing #322, which had to correct all ten plugins' schema_version_range at once — every one of them was behind the schemas its product group actually ships.
The state before #322
| plugin |
declared max |
shipped max |
| aluminium |
1.1.0 |
1.2.0 |
| battery |
2.6.0 |
2.7.0 |
| construction |
1.1.0 |
1.2.0 |
| detergent |
1.1.0 |
1.2.0 |
| electronics |
1.2.0 |
1.4.0 |
| furniture |
1.1.0 |
1.3.0 |
| steel |
1.1.0 |
1.2.0 |
| textile |
1.2.0 |
1.3.0 |
| toy |
1.1.0 |
1.2.0 |
| tyre |
1.0.0 |
1.1.0 |
Ten for ten. #322 corrected all of them, and a stale comment in product-group-battery (v1.0.0 through v2.5.0 against a declared 2.7.0) was corrected separately in the same branch — so the value drifted and the prose describing it drifted, independently.
Why it will happen again
Nothing compares the two. Adding crates/dpp-domain/schemas/<group>/vX.Y.Z.json is a single file addition by design, and no gate asks whether the plugin for that group claims to accept it. The ten values were simply re-typed by hand in #322 and will be stale again after the next schema bump.
plugins/* being outside the workspace is not the obstacle here — dpp-tests can read a plugin's lib.rs as text and the schema directory as a listing, which is exactly how the table above was produced.
Why it is urgency/backlog and not higher
The declared range is currently inert. The host calls check_compatibility(…, None, …) and None skips the schema check, so a wrong range changes no behaviour today. That is also precisely why the drift went unnoticed for ten versions across ten crates: the value is read by nothing, so nothing complains.
That makes it a trap rather than a live defect — the day dispatch-time schema enforcement is turned on, ten wrong bounds become ten refusals or ten silent acceptances, depending on which direction they are wrong. The fix is cheap now and load-bearing later.
Suggested shape
A test in dpp-tests asserting, for each plugins/product-group-<g>/, that the declared max_version equals the highest vX.Y.Z.json under crates/dpp-domain/schemas/<g>/ — and that the group directory exists at all, since a plugin naming a group with no schemas is the other half of the same question.
Watch it fail before trusting it: bump a schema without touching the plugin and confirm it goes red.
Found while reviewing #322, which had to correct all ten plugins'
schema_version_rangeat once — every one of them was behind the schemas its product group actually ships.The state before #322
Ten for ten. #322 corrected all of them, and a stale comment in
product-group-battery(v1.0.0 through v2.5.0against a declared 2.7.0) was corrected separately in the same branch — so the value drifted and the prose describing it drifted, independently.Why it will happen again
Nothing compares the two. Adding
crates/dpp-domain/schemas/<group>/vX.Y.Z.jsonis a single file addition by design, and no gate asks whether the plugin for that group claims to accept it. The ten values were simply re-typed by hand in #322 and will be stale again after the next schema bump.plugins/*being outside the workspace is not the obstacle here —dpp-testscan read a plugin'slib.rsas text and the schema directory as a listing, which is exactly how the table above was produced.Why it is
urgency/backlogand not higherThe declared range is currently inert. The host calls
check_compatibility(…, None, …)andNoneskips the schema check, so a wrong range changes no behaviour today. That is also precisely why the drift went unnoticed for ten versions across ten crates: the value is read by nothing, so nothing complains.That makes it a trap rather than a live defect — the day dispatch-time schema enforcement is turned on, ten wrong bounds become ten refusals or ten silent acceptances, depending on which direction they are wrong. The fix is cheap now and load-bearing later.
Suggested shape
A test in
dpp-testsasserting, for eachplugins/product-group-<g>/, that the declaredmax_versionequals the highestvX.Y.Z.jsonundercrates/dpp-domain/schemas/<g>/— and that the group directory exists at all, since a plugin naming a group with no schemas is the other half of the same question.Watch it fail before trusting it: bump a schema without touching the plugin and confirm it goes red.