RPC服务GetData接口中context.Err()在调用完成时的技术问询

Let’s walk through the different scenarios for context.Err() in your code and clarify what happens when the request completes or is canceled.

First, Let’s Simplify Your Goroutine (Minor Optimization) #

Before diving into context behavior, note that your goroutine has redundant logic with the test variable. You can simplify it to this cleaner, equivalent code:

go func(ctx context.Context) {
    select {
    case <-ctx.Done():
        log.Info(ctx.Err())
    }
}(ctx)

The loop and test check aren’t necessary—once ctx.Done() triggers, the goroutine will log the error and exit immediately.

Scenario 1: Client Waits for the Full 5 Seconds (Normal Completion) #

When the client stays connected and waits for fetchData to finish (the full 5 seconds), your GetData handler returns the response to the RPC framework.

Most Go RPC frameworks (like gRPC) automatically cancel the request context once the handler returns to clean up resources tied to the completed request. This means:

• Your background goroutine will receive a signal on ctx.Done() shortly after GetData returns.
• ctx.Err() will be context.Canceled here, since the framework is explicitly canceling the context to wrap up the request lifecycle.

Scenario 2: Client Cancels the Request Mid-Process #

If the client cancels the request before fetchData finishes (e.g., disconnects early, or calls cancel() on their end of the context):

• The context will be canceled immediately, so your goroutine’s select will trigger right away.
• ctx.Err() will again be context.Canceled—this is the standard error for explicitly canceled contexts.
• Critical note: Your fetchData function doesn’t accept the ctx right now. That means it will keep running for the full 5 seconds even if the client cancels. To fix this, modify fetchData to take ctx and check ctx.Done() periodically (or pass it to underlying network calls), so you can abort early when the request is canceled.

Scenario 3: Context Hits a Deadline (If Configured) #

If your RPC request has a timeout/deadline set (e.g., the client specified a maximum wait time), and fetchData takes longer than that deadline:

• The context will be canceled automatically when the deadline is exceeded.
• ctx.Err() will be context.DeadlineExceeded instead of Canceled.
• Again, making fetchData respect the ctx will let you stop unnecessary work as soon as the deadline passes.

Key Takeaways #

• In almost all request completion scenarios (normal finish, client cancellation, deadline hit), your background goroutine will eventually see ctx.Err() as either context.Canceled or context.DeadlineExceeded.
• Always pass the request context to long-running functions like fetchData to enable early termination and avoid wasting resources.
• Your background goroutine is safe—it will exit automatically once the context is canceled, so you don’t have to worry about goroutine leaks.

内容的提问来源于stack exchange，提问作者Sumit Agarwal