Problem
Two dead-code/documentation defects in the federated collector that mislead an operator about what is
actually running.
1. The rate limiter is inert at every real call site
RATE_LIMIT = { limit: 6, windowMs: 60_000 } (src/orb/federated-collector.ts:40) is documented as "a
best-effort background sync has no business hammering a peer's collector". But rateLimitAllows opens
with if (!opts.bucket) return true; (:78-81) and bucket is caller-owned.
The only production caller is buildFederatedBenchmark, which forwards opts straight through from
src/api/routes.ts:1716, where the object is { now, timeoutMs: 5_000, maxAttempts: 1 } — no bucket.
A repo-wide grep for bucket: finds it exclusively in test/unit/federated-collector.test.ts.
So the documented abuse protection is inert at 100% of real call sites. With the feature enabled, every
maintainer dashboard refresh issues an unthrottled GET at the peer collector — N maintainers hitting
refresh is N requests/second, not 6/minute.
Fix: hold a module-level LocalRateBucket inside federated-collector.ts and default to it, rather
than making the limiter opt-in from the caller.
2. collectorMode: "push" is a configuration that does nothing
pushFederatedBundle has zero production callers — only test/unit/federated-collector.test.ts. And
resolveCollectorEndpoint(m, "pull") returns null for a push-configured manifest. So an operator who
configures push-only gets a silently no-op feature with no warning anywhere.
Fix: wire pushFederatedBundle into the export tick, or delete it along with the push/both modes
and reject those values in manifest validation.
3. Stale comments contradict the post-#9046 code
src/api/routes.ts:4399-4400 and :6608-6610 still describe the ingest gate as "unset ⇒ OPEN ingress /
FAIL-OPEN by default". isAuthorizedIngest two lines below now begins if (!configuredToken) return false;. A reader auditing the auth posture from the comments reaches the opposite conclusion from the
code.
Impact
Low individually, but this is the class that produced #9049 and #9040 — a control that reads as configured
and does nothing, plus comments that actively mislead the next auditor. Worth clearing while the
federated feature is still inert and the change is free.
Requirements
As above, per part. Add a test asserting the rate limiter engages with no caller-supplied bucket, and
delete or wire the push path rather than leaving it half-present.
Test Coverage Requirements
99%+ patch coverage, branch-counted; both arms of the default-bucket path.
Links & Resources
maintainer-only — dead controls and doc accuracy.
Problem
Two dead-code/documentation defects in the federated collector that mislead an operator about what is
actually running.
1. The rate limiter is inert at every real call site
RATE_LIMIT = { limit: 6, windowMs: 60_000 }(src/orb/federated-collector.ts:40) is documented as "abest-effort background sync has no business hammering a peer's collector". But
rateLimitAllowsopenswith
if (!opts.bucket) return true;(:78-81) andbucketis caller-owned.The only production caller is
buildFederatedBenchmark, which forwardsoptsstraight through fromsrc/api/routes.ts:1716, where the object is{ now, timeoutMs: 5_000, maxAttempts: 1 }— no bucket.A repo-wide grep for
bucket:finds it exclusively intest/unit/federated-collector.test.ts.So the documented abuse protection is inert at 100% of real call sites. With the feature enabled, every
maintainer dashboard refresh issues an unthrottled GET at the peer collector — N maintainers hitting
refresh is N requests/second, not 6/minute.
Fix: hold a module-level
LocalRateBucketinsidefederated-collector.tsand default to it, ratherthan making the limiter opt-in from the caller.
2.
collectorMode: "push"is a configuration that does nothingpushFederatedBundlehas zero production callers — onlytest/unit/federated-collector.test.ts. AndresolveCollectorEndpoint(m, "pull")returns null for a push-configured manifest. So an operator whoconfigures push-only gets a silently no-op feature with no warning anywhere.
Fix: wire
pushFederatedBundleinto the export tick, or delete it along with thepush/bothmodesand reject those values in manifest validation.
3. Stale comments contradict the post-#9046 code
src/api/routes.ts:4399-4400and:6608-6610still describe the ingest gate as "unset ⇒ OPEN ingress /FAIL-OPEN by default".
isAuthorizedIngesttwo lines below now beginsif (!configuredToken) return false;. A reader auditing the auth posture from the comments reaches the opposite conclusion from thecode.
Impact
Low individually, but this is the class that produced #9049 and #9040 — a control that reads as configured
and does nothing, plus comments that actively mislead the next auditor. Worth clearing while the
federated feature is still inert and the change is free.
Requirements
As above, per part. Add a test asserting the rate limiter engages with no caller-supplied bucket, and
delete or wire the push path rather than leaving it half-present.
Test Coverage Requirements
99%+ patch coverage, branch-counted; both arms of the default-bucket path.
Links & Resources
src/orb/federated-collector.ts~40, ~78-81, ~137, ~169-170;src/orb/federated-benchmark.ts~53;src/api/routes.ts~1716-1720, ~4399-4400, ~6608-6610same files, but not the wiring)
maintainer-only — dead controls and doc accuracy.