Measured
dig-node implements and serves two control methods that have no declaration anywhere in this crate:
control.peers.setBancontrol.peers.setPoolConfig
Found while adding control.capsule.fetch (#22) — a grep for existing conventions turned up neither
method, so they are not a catalog pattern to follow; they are absent.
Why it matters
This crate exists so a consumer can call the control plane through typed contract calls rather than
hand-rolled method strings. dig-app's gateway was just refactored onto exactly that basis
(DIG-Network/dig-app#240), and these two are the reason it still carries an explicitly-named
EngineCall::uncatalogued escape hatch.
So the gap is not cosmetic: two live server methods are reachable only by bypassing the contract, and
the bypass has to stay open for as long as they are undeclared. dig-app pins them as a known exception in
every_gateway_method_is_in_the_shared_catalog_or_a_known_gap — that test is the current record of this
gap, and it should be able to shrink.
What to do
Declare both, mirroring an existing peers-category method, then let dig-app drop its two uncatalogued
entries. Additive, so a minor.
Check first whether either is intended to stay out. A method deliberately excluded from the catalog —
for instance because it is an operator-only surface with a different authorization story — is a legitimate
answer, but then it should be recorded as deliberate here, so the next reader does not file this again.
Right now the absence is indistinguishable from an oversight.
Related
DIG-Network/dig-node-control-interface#22 — where the gap surfacedDIG-Network/dig-app#240 — the gateway refactor that carries the exception
Measured
dig-nodeimplements and serves two control methods that have no declaration anywhere in this crate:control.peers.setBancontrol.peers.setPoolConfigFound while adding
control.capsule.fetch(#22) — a grep for existing conventions turned up neithermethod, so they are not a catalog pattern to follow; they are absent.
Why it matters
This crate exists so a consumer can call the control plane through typed contract calls rather than
hand-rolled method strings. dig-app's gateway was just refactored onto exactly that basis
(
DIG-Network/dig-app#240), and these two are the reason it still carries an explicitly-namedEngineCall::uncataloguedescape hatch.So the gap is not cosmetic: two live server methods are reachable only by bypassing the contract, and
the bypass has to stay open for as long as they are undeclared. dig-app pins them as a known exception in
every_gateway_method_is_in_the_shared_catalog_or_a_known_gap— that test is the current record of thisgap, and it should be able to shrink.
What to do
Declare both, mirroring an existing peers-category method, then let dig-app drop its two uncatalogued
entries. Additive, so a minor.
Check first whether either is intended to stay out. A method deliberately excluded from the catalog —
for instance because it is an operator-only surface with a different authorization story — is a legitimate
answer, but then it should be recorded as deliberate here, so the next reader does not file this again.
Right now the absence is indistinguishable from an oversight.
Related
DIG-Network/dig-node-control-interface#22— where the gap surfacedDIG-Network/dig-app#240— the gateway refactor that carries the exception