-
Notifications
You must be signed in to change notification settings - Fork 10
Add Request ID Tracking for Enhanced Debugging and Distributed Tracing #674
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
714fc60
4b553de
d91e2b0
14f2fec
2976f91
d1f781b
17c0ab1
7f7c231
62cc2e8
ff2c58a
ab3153f
cd65975
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,43 @@ | ||
| package admin | ||
|
|
||
| import ( | ||
| "context" | ||
| "net/http" | ||
| "testing" | ||
| ) | ||
|
|
||
| func TestPrepareRequest_WithRequestID(t *testing.T) { | ||
| client := NewAPIClient(NewConfiguration()) | ||
|
|
||
| // Test with request ID in context | ||
| ctx := context.WithValue(context.Background(), "X-Request-ID", "test-request-123") | ||
| req, err := client.prepareRequest(ctx, "/api/test", "GET", nil, nil, nil, nil, nil) | ||
|
|
||
| if err != nil { | ||
| t.Fatalf("PrepareRequest failed: %v", err) | ||
| } | ||
|
|
||
| // Check that request ID header was added | ||
| requestID := req.Header.Get("X-Request-ID") | ||
| if requestID != "test-request-123" { | ||
| t.Errorf("Expected X-Request-ID header 'test-request-123', got '%s'", requestID) | ||
| } | ||
| } | ||
|
|
||
| func TestPrepareRequest_WithoutRequestID(t *testing.T) { | ||
| client := NewAPIClient(NewConfiguration()) | ||
|
|
||
| // Test without request ID in context (should work as before) | ||
| ctx := context.Background() | ||
| req, err := client.prepareRequest(ctx, "/api/test", "GET", nil, nil, nil, nil, nil) | ||
|
|
||
| if err != nil { | ||
| t.Fatalf("PrepareRequest failed: %v", err) | ||
| } | ||
|
|
||
| // Check that no request ID header was added | ||
| requestID := req.Header.Get("X-Request-ID") | ||
| if requestID != "" { | ||
| t.Errorf("Expected no X-Request-ID header, got '%s'", requestID) | ||
| } | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -219,3 +219,14 @@ func (o *ApiError) HasReason() bool { | |
| func (o *ApiError) SetReason(v string) { | ||
| o.Reason = &v | ||
| } | ||
|
|
||
| func (a *ApiError) GetContextualError(ctx context.Context) string { | ||
| baseError := a.Error() | ||
|
|
||
| // Check if context has request ID | ||
| if requestID, ok := ctx.Value("X-Request-ID").(string); ok && requestID != "" { | ||
| return fmt.Sprintf("%s (RequestID: %s)", baseError, requestID) | ||
| } | ||
|
|
||
| return baseError | ||
| } | ||
|
Comment on lines
+223
to
+232
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there a reason we want to place this utility logic within ApiError model? Potentially this can be simplified to a utility function separate from ApiError which simply obtains the RequestID from the Go context.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's a great point! You're absolutely right that putting this logic in the ApiError model creates unnecessary coupling. A utility function approach would be much cleaner and more reusable. I can simplify this by: 1- Removing the This keeps the models clean and gives users more flexibility in how they format error messages. Would you prefer I implement it as a simple |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,36 @@ | ||
| package admin | ||
|
|
||
| import ( | ||
| "context" | ||
| "testing" | ||
| ) | ||
|
|
||
| func TestApiError_GetContextualError(t *testing.T) { | ||
| // Create a sample API error | ||
| detail := "Project not found" | ||
| reason := "Resource not found" | ||
| apiError := &ApiError{ | ||
| Detail: &detail, | ||
| Error: 404, | ||
| ErrorCode: "RESOURCE_NOT_FOUND", | ||
| Reason: &reason, | ||
| } | ||
|
|
||
| // Test with request ID in context | ||
| ctx := context.WithValue(context.Background(), "X-Request-ID", "debug-456") | ||
| contextualError := apiError.GetContextualError(ctx) | ||
|
|
||
| expected := "404 RESOURCE_NOT_FOUND Resource not found: Project not found (RequestID: debug-456)" | ||
| if contextualError != expected { | ||
| t.Errorf("Expected: %s\nGot: %s", expected, contextualError) | ||
| } | ||
|
|
||
| // Test without request ID in context | ||
| ctx = context.Background() | ||
| contextualError = apiError.GetContextualError(ctx) | ||
|
|
||
| expected = "404 RESOURCE_NOT_FOUND Resource not found: Project not found" | ||
| if contextualError != expected { | ||
| t.Errorf("Expected: %s\nGot: %s", expected, contextualError) | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Related to the statement
Has there been a request from the support team to add this information? Do we know if they are capable of leveraging these values/find them useful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a fair question. I made an assumption that support could leverage these values, but I don't have confirmation from the support team or know the right channel to ask them. Could you help me connect with the right people on the support team to get their opinion?
In the meantime, the primary value I see is actually for client-side debugging and tracing in distributed applications. The main benefits would be:
Would you be able to help me either:
1- Connect with the support team to understand if they'd find client-provided request IDs valuable, or
2- Should we focus on the client-side benefits for now and consider the support angle separately?
I'm happy to adjust the PR based on whatever feedback we get from support.