What changed?

A new interceptor has been written and added to frontend's FX chain that logs slow gRPC requests. Requests are logged with their elapsed time, and more importantly, their extracted request IDs/workflow tags, so on-call can quickly determine the problematic IDs.

This is what the log line might look like:

{
  "level": "warn",
  "ts": "2025-05-06T15:34:35.600-0700",
  "msg": "Slow gRPC call for 'temporal.api.workflowservice.v1.WorkflowService/DescribeWorkflowExecution', took 6.000857875s",
  "wf-id": "fc48187c-3df0-4c6e-b898-027ffe3e9066",
  "wf-run-id": "0196a7bc-73ec-7f1b-890d-a0bbbf63ac21",
  "logging-call-at": "/Users/lina/code/temporal/common/rpc/interceptor/slow_request_logger.go:59"
}

Why?

Because these request IDs are often deep within a protobuf request body, they aren't visible through Envoy/Chronicle logs, so although we can often see that a customer is experiencing request-reply latency, we have little else to follow-up on without asking them for more information.

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)
• added new functional test(s)

Potential risks

We could end up with spammy log lines if we have lots of methods which regularly complete over the threshold, that aren't on the ignore list. I based the ignore and threshold on the frontend API dashboards across a few cells.