You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because the CorrelationIdHandler class is internal, we are running into issues causing problems in the implementation of correlation forwarding in our companies enterprise architecture.
We have a package that bundles the correlation forwarding registration with a few feature flags:
EnableCorrelationForwarding feature flag.
This tells the correlation id package to register a client with CorrelationIdForwarding in the DI container: services.AddHttpClient(correlationIdForwardingHttpClient).AddCorrelationIdForwarding();
We also have LOTS of applications, and are constantly building new ones. In the hundreds.
In an effort to save code, and because we often have applications interface with the same systems, we create NuGet package providers to call downstream services, specifically where the client we just registered is actually used: client = clientFactory.CreateClient(config.CorrelationIdForwardingHttpClient);
The issue is that we also have other correlation forwarding models that are highly specific to the systems we interface with that is all legacy code. In a nutshell:
(legacy system - to - legacy system)
TransactionId-To-TransactionId Forwarding Model:
We pass around a GUID through application layers and imbedded in our requests to identify a specific transaction set uniquely in our logs (prior to implementing the correlation id package as a standard in our apps).
(new system - to - legacy system)
CorrelationId-To-TransactionId Forwarding Model
We take the Correlation-Id of App A and pass it as a Transaction-Id to App B by using the ICorrelationContextAccessor and embedding the CorrelationId into the outbound request.
(legacy system - to - new system)
TransactionId-To-CorrelationId Forwarding Model
An app that uses a TransactionId embeds it into the outbound HttpRequest header in a format that the downstream service expects to use as a CorrelationId.
(new system - to - new system)
CorrelationId-To-CorrelationId Forwarding Model
Automated correlation forwarding as it is present in this package.
Due to the significant differences between the providers and the fact that the correlation forwarding models are encapsulated within NuGet packages and versioned, we face challenges in keeping everything organized. Each NuGet package provider publishes a version to an internal NuGet server that corresponds to the specific implementation of the correlation forwarding model it supports. As a result, we often encounter situations where developers use incorrect provider versions or fail to implement them properly, causing confusion and malfunctions.
To address this, we've implemented a creative solution: during the setup process (which is condensed into a registration extension method), the provider checks the Dependency Injection (DI) container for the necessary components to properly implement the desired correlation forwarding model. If the configuration is incorrect, the provider throws a runtime InvalidOperationException with a clear, explicit message, guiding the developer to correct the misconfiguration.
However, since CorrelationIdHandler is marked as internal, I am unable to check the DI container to verify if it has already been registered. This prevents us from confirming that correlation forwarding has been correctly configured in our package (for the CorrelationId-To-CorrelationId Forwarding Model), which is crucial to ensure the transactional integrity of requests between systems. This limitation is causing significant issues for us. We kindly request that you reconsider this design decision.
The text was updated successfully, but these errors were encountered:
Because the CorrelationIdHandler class is internal, we are running into issues causing problems in the implementation of correlation forwarding in our companies enterprise architecture.
We have a package that bundles the correlation forwarding registration with a few feature flags:
EnableCorrelationForwarding
feature flag.services.AddHttpClient(correlationIdForwardingHttpClient).AddCorrelationIdForwarding();
We also have LOTS of applications, and are constantly building new ones. In the hundreds.
In an effort to save code, and because we often have applications interface with the same systems, we create NuGet package providers to call downstream services, specifically where the client we just registered is actually used:
client = clientFactory.CreateClient(config.CorrelationIdForwardingHttpClient);
The issue is that we also have other correlation forwarding models that are highly specific to the systems we interface with that is all legacy code. In a nutshell:
(legacy system - to - legacy system)
TransactionId-To-TransactionId Forwarding Model:
(new system - to - legacy system)
CorrelationId-To-TransactionId Forwarding Model
(legacy system - to - new system)
TransactionId-To-CorrelationId Forwarding Model
(new system - to - new system)
CorrelationId-To-CorrelationId Forwarding Model
Due to the significant differences between the providers and the fact that the correlation forwarding models are encapsulated within NuGet packages and versioned, we face challenges in keeping everything organized. Each NuGet package provider publishes a version to an internal NuGet server that corresponds to the specific implementation of the correlation forwarding model it supports. As a result, we often encounter situations where developers use incorrect provider versions or fail to implement them properly, causing confusion and malfunctions.
To address this, we've implemented a creative solution: during the setup process (which is condensed into a registration extension method), the provider checks the Dependency Injection (DI) container for the necessary components to properly implement the desired correlation forwarding model. If the configuration is incorrect, the provider throws a runtime
InvalidOperationException
with a clear, explicit message, guiding the developer to correct the misconfiguration.However, since
CorrelationIdHandler
is marked as internal, I am unable to check the DI container to verify if it has already been registered. This prevents us from confirming that correlation forwarding has been correctly configured in our package (for the CorrelationId-To-CorrelationId Forwarding Model), which is crucial to ensure the transactional integrity of requests between systems. This limitation is causing significant issues for us. We kindly request that you reconsider this design decision.The text was updated successfully, but these errors were encountered: