Aaron Abbott

> I was unable to use a more recent version of `grpc-io` due to this library's upper restriction on the version of protobuf. Protobuf 5 was released in March and...

@Sovietaced gotcha I appreciate the PR. I reached out internally regarding https://github.com/googleapis/python-api-common-protos/pull/221 and there is apparently more work needed to support protobuf 5 and should have a fix in the...

Looks like the release as made and we can move this PR forward https://github.com/googleapis/python-api-common-protos/releases/tag/v1.63.1

Related: https://github.com/open-telemetry/opentelemetry-python/issues/3932#issuecomment-2146072966 I'm going to bring this up in the SIG call but I'm nervous to move forward with this change even with CI passing without first re-generating the code...

We didn't really come to a conclusion. I opened https://github.com/open-telemetry/opentelemetry-python/issues/3958 for discussion

@Sovietaced thanks again for your patience, do you still have time to work on this? I think we have reached a decision to move forward with only supporting protobuf 5+...

No worries @Sovietaced appreciate your work on this so far. This PR helped move the discussion forward. Since we are scoping down, I will probably open a separate PR

What if we capture the parameter names and parameter numbers. For DB conventions, it's been like this.

Since the [protobuf field is `sfixed64`](https://github.com/open-telemetry/opentelemetry-proto/blob/9833c48ed163156e492882e35aa1a1263a1f6a01/opentelemetry/proto/metrics/v1/metrics.proto#L394), possibly the exporter should handle this case eagerly or somehow convert it to be in the correct range. However, the metric `process.runtime.cpython.context_switches` is coming...

@pmcollins any way you can check the output of `psutil.Process(os.getpid()).num_ctx_switches()` when this happens and see if it an SDK issue or psutil issue?