The reporting report-definition-templates forwarder is dead
Table of Contents
This page is a capture in the inbox bucket of the product backlog — a pre-sprint idea, not yet pulled into a sprint as a story.
1. What
reporting.v1.report-definition-templates.list is registered by
projects/ores.reporting/core/src/messaging/registrar.cpp and forwards to dq's
dq.v1.report-definition-templates.list, decoding dq's request type and
replying with dq's response type. No client sends it: the subject occurs only in
the forwarding handler itself. The forwarder is therefore unreachable.
2. Why
Its request and response are declared in a handler header rather than in a
*_protocol.hpp, so check_protocol_twin_coverage.py — which globs
api/include/*/messaging/*_protocol.hpp — cannot see them and cannot demand
their TypeScript twins. That is the gate's blind spot as much as the
component's defect: a wire type parked outside a protocol header escapes every
check the twin gate makes.
The reporting clean pass already records this. Either the forwarder is deleted, or its messages move to an operation model and gain twins, which is what dq did for its own half.
3. References
projects/ores.reporting/core/include/ores.reporting.core/messaging/report_definition_template_handler.hpp— the redeclared request, the subject and the forwarding body.projects/ores.reporting/core/src/messaging/registrar.cpp— the registration.