Skip to content

fix rpcz root client span lifetime (#3420) - #3421

Open
lh2debug-2 wants to merge 1 commit into
apache:masterfrom
lh2debug-2:fix-rpcz-root-client-span-lifetime
Open

fix rpcz root client span lifetime (#3420)#3421
lh2debug-2 wants to merge 1 commit into
apache:masterfrom
lh2debug-2:fix-rpcz-root-client-span-lifetime

Conversation

@lh2debug-2

Copy link
Copy Markdown

Fixes #3420

Summary

This change keeps the current RPC span alive from Controller until the RPC finishes, SubmitSpan runs, or the Controller is reset. This lets root client spans without a local parent be submitted to rpcz instead of being destroyed after the caller-side temporary shared_ptr goes out of scope.

Child client spans remain linked to their parent through weak local-parent references and parent-owned client lists, so they are still serialized under their parent without introducing shared_ptr cycles.

Testing

  • Built brpc successfully with CMake in /tmp/brpc-community-build-rpcz.
  • Ran a small local demo test verifying that a root client span remains alive after the caller-side shared_ptr is released while Controller still owns the span.

Note: the local CMake build used a temporary include-only workaround for an unrelated UBShm timer_mgr.cpp atomic_fetch_add/sub compile issue on GCC 8; no UBShm source change is included in this PR.

Keep the current RPC span alive from Controller until the RPC finishes,
SubmitSpan runs, or the Controller is reset. This lets root client spans
without a local parent be submitted to rpcz instead of being destroyed
after the caller-side temporary shared_ptr goes out of scope.

Child client spans remain linked to their parent through weak local-parent
references and parent-owned client lists, so they are still serialized
under their parent without introducing shared_ptr cycles.
@wwbmmm

wwbmmm commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

There is a scenario like this:

  1. Server receive a request and create a local parent span
  2. During processing this request, a client start a new async call, create a child span
  3. Server send the response before the client return, the local parent span submit, and also submit the child span
  4. The client's response return, because the client span's parent is now expired, so the client will submit the span, too.
  5. Consequently, the client span is submitted twice.

Is that right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

rpcz does not record root client spans when Controller only keeps a weak_ptr to Span

2 participants