[JS] Retriever/embedder/indexer spans missing input/output in Genkit Monitoring

[Champkinz]

Description
When using Genkit Monitoring (Firebase Console), retriever spans show "(No input/output available)" in the trace viewer, while generate and tool spans display their input/output correctly.

Root Cause
In @genkit-ai/google-cloud v1.29.0, the AdjustingTraceExporter.tickTelemetry() method in gcpOpenTelemetry.ts only writes structured log entries for these span types:

if (type === 'action' && subtype === 'model') {
  generateTelemetry.tick(span, this.logInputAndOutput, this.projectId);
}
if (type === 'action' && subtype === 'tool') {
  // empty
}
if (type === 'action' || type === 'flow' || type == 'flowStep' || type == 'util') {
  actionTelemetry.tick(span, this.logInputAndOutput, this.projectId);
}

Spans with genkit:type = "retriever" (and also "embedder", "indexer") don't match any condition, so no structured logs are written for them. Since redactInputOutput() replaces raw genkit:input/genkit:output attributes with before Cloud Trace export, the monitoring dashboard has no source of input/output data for these span types.

Additionally, even if retriever/embedder/indexer were added to the type check, actionTelemetry.tick() currently only logs input/output for tool subtype and generate action name.

Expected Behavior
Retriever, embedder, and indexer spans should have their input/output visible in the Genkit Monitoring trace viewer, similar to how generate and tool spans work.

Screenshot

Environment

• genkit: 1.29.0
• @genkit-ai/google-cloud: 1.29.0
• @genkit-ai/firebase: 1.29.0
• Node.js: 22
• Firebase Cloud Functions v2

Reproduction

1. Define a Firestore retriever using defineFirestoreRetriever() from @genkit-ai/firebase
2. Call ai.retrieve() within a Genkit flow
3. Deploy to Firebase Cloud Functions with enableFirebaseTelemetry()
4. View the trace in Genkit Monitoring dashboard
5. The retriever step shows "(No input/output available)" while the generate step shows full input/output

[MichaelDoyle]

Hey @Champkinz - thanks for reporting. How do you typically use this information to debug?

We are aware of this - it's omission was originally by design. But if there is a good use case, I can follow up with the team to get it prioritized.