Adding CorrelationId to track requests#171
Conversation
There was a problem hiding this comment.
Pull request overview
This pull request adds correlation ID support to track requests across different interfaces in the Agent365 CLI tool. The implementation introduces a standardized way to generate and propagate correlation IDs throughout HTTP requests for better observability and request tracing.
Changes:
- Added
x-ms-correlation-idheader support to HttpClientFactory with automatic GUID generation when not provided - Updated all HTTP client creation calls to accept and propagate optional correlation IDs
- Added correlation ID generation at workflow entry points across commands and services
- Updated test mocks to accommodate the new optional correlationId parameter
Reviewed changes
Copilot reviewed 14 out of 14 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| HttpClientFactory.cs | Added CorrelationIdHeaderName constant, updated CreateAuthenticatedClient to accept optional correlationId parameter, added GenerateCorrelationId helper method |
| IBotConfigurator.cs | Added optional correlationId parameter to both interface methods |
| BotConfigurator.cs | Updated method signatures and passed correlationId to HttpClientFactory |
| DelegatedConsentService.cs | Added correlation ID generation and logging at workflow entry point |
| Agent365ToolingService.cs | Added correlation ID generation for all public API methods |
| A365CreateInstanceRunner.cs | Added correlation ID generation and propagation across multiple Graph API calls |
| SetupHelpers.cs | Added optional correlationId parameter to RegisterBlueprintMessagingEndpointAsync |
| BlueprintSubcommand.cs | Added correlation ID generation in command handler and passed to helper methods |
| AllSubcommand.cs | Added correlation ID generation in command handler |
| PublishCommand.cs | Added correlation ID generation and logging |
| DevelopCommand.cs | Added correlation ID generation in CallDiscoverToolServersAsync |
| CleanupCommand.cs | Added correlation ID generation (with timing issue) |
| HttpClientFactoryTests.cs | Added comprehensive tests for correlation ID functionality |
| CleanupCommandTests.cs | Updated mocks to accept new optional correlationId parameter |
| // Generate correlation ID at workflow entry point | ||
| var correlationId = HttpClientFactory.GenerateCorrelationId(); | ||
|
|
||
| // Set default handler for 'a365 cleanup' (without subcommand) - cleans up everything | ||
| cleanupCommand.SetHandler(async (configFile, verbose) => | ||
| { | ||
| await ExecuteAllCleanupAsync(logger, configService, botConfigurator, executor, agentBlueprintService, confirmationProvider, federatedCredentialService, configFile); | ||
| await ExecuteAllCleanupAsync(logger, configService, botConfigurator, executor, agentBlueprintService, confirmationProvider, federatedCredentialService, configFile, correlationId: correlationId); | ||
| }, configOption, verboseOption); | ||
|
|
||
| // Add subcommands for granular control | ||
| cleanupCommand.AddCommand(CreateBlueprintCleanupCommand(logger, configService, botConfigurator, executor, agentBlueprintService, federatedCredentialService)); | ||
| cleanupCommand.AddCommand(CreateBlueprintCleanupCommand(logger, configService, botConfigurator, executor, agentBlueprintService, federatedCredentialService, correlationId: correlationId)); |
There was a problem hiding this comment.
The correlation ID is being generated once at command creation time (when CreateCommand is called) rather than at command execution time. This means all invocations of the cleanup command will share the same correlation ID, defeating the purpose of request tracing.
The correlation ID should be generated inside the SetHandler lambda or at the beginning of ExecuteAllCleanupAsync so that each command invocation gets a unique ID.
Adding CorrelationId to track requests across different interfaces