[Daniel Botros (danielbotros)]

Problem

Data capture froze a collector's component_type from the resource's single configured API and passed the composite resource straight to the collector constructor. For a composite serving several co-equal APIs this:

1. mis-tagged data — a camera+sensor's Readings were tagged rdk:component:camera, which ingestion rejects as non-sensor; and
2. could not build the collector at all — constructors type-assert their concrete API (resource.(Sensor)), and a composite wrapper satisfies none.

Change

Resolve each capture method's owning API from the resource's served API set at collector-build time, instead of assuming the configured API owns every method.

• captureAPIForMethod resolves the owner over resource.APIsOf(res) via the collector registry: a method implemented by exactly one served API tags under that API (Readings→sensor, GetImage→camera); a method several served APIs share (e.g. DoCommand) stays under the configured API; a single-API resource is unchanged.
• The owning API flows through the collector-metadata key, so a method name shared across a composite's APIs keys into distinct per-API streams.
• buildCollector unwraps the composite to the owning sub-resource (SubresourceForAPI) before calling the constructor, and uses the owning API for component_type, capture-file layout, and metadata.
• The capture-control auto-enable path resolves the owning API the same way instead of guessing from res.Name().API.

Tests

New TestCaptureAPIForMethod builds a real composite and asserts owning-API resolution (owned → that API, shared → configured, none → configured, single-API unchanged). Existing capture + builtin suites updated and green; go build ./... and golangci-lint clean.

End-to-end validation

Validated against a preview deploy of the app-side match-by-name ingestion (app #14053):

• Built viam-server from this stack and ran the complexcombomodule composite (combodevice — serves camera + movement_sensor + custom gizmo) on a machine configured under camera, with data capture + sync.
• Captured Readings and Position (movement_sensor methods) plus DoCommand.
• Readings/Position captured and tagged rdk:component:movement_sensor (owning API ≠ the configured camera); DoCommand — owned by both camera and movement_sensor — tagged rdk:component:camera (configured API, since owners > 1). Confirmed in the on-disk capture layout and over sync.
• The movement_sensor-tagged data synced and ingested against the camera-configured entry on the deploy — the match-by-name path #14053 adds.

Stacked on #6543 (composable-apis-p3e-consumers).

🤖 Generated with Claude Code