Summary

trace_call() wraps every Spanner operation with a bare MetricsCapture() that creates a MetricsTracer without project_id or instance_id. Since every caller of trace_call already provides its own MetricsCapture(resource_info) with correct labels, the one inside trace_call is redundant and harmful.

The redundant tracer records operation metrics (via record_operation_completion()) with incomplete resource labels on every operation. Because OpenTelemetry uses cumulative aggregation, these orphan data points persist for the process lifetime and get re-exported every 60 seconds by the PeriodicExportingMetricReader. Cloud Monitoring rejects them with:

INVALID_ARGUMENT: One or more TimeSeries could not be written:
timeSeries[...]: the set of resource labels is incomplete, missing (instance_id)

Root cause

When Python evaluates with trace_call(...) as span, MetricsCapture(resource_info):, the execution order is:

1. trace_call.__enter__() creates internal bare MetricsCapture() -> tracer_A (no project_id/instance_id)
2. Caller's MetricsCapture(resource_info).__enter__() -> tracer_B (has correct labels, overwrites tracer_A in context var)
3. Body runs -- gRPC calls use tracer_B via MetricsInterceptor
4. Caller's MetricsCapture.__exit__() -> records correct metrics on tracer_B, resets context to tracer_A
5. trace_call.__exit__() -> records metrics on tracer_A with incomplete labels

History

• PR feat: Add Attempt, Operation and GFE Metrics python-spanner#1302 introduced the metrics system with bare MetricsCapture() everywhere.
• PR feat: implement native asyncio support via Cross-Sync python-spanner#1509 changed all caller sites to MetricsCapture(self._resource_info) but did not remove the bare one inside trace_call.

Fix

Remove the bare MetricsCapture() from trace_call. All ~27 call sites already provide their own MetricsCapture with correct resource labels.

Testing

All existing unit tests pass. The change only removes the redundant context manager; span/trace behavior is unchanged.

Fixes #16173