Skip to content
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

CorrelationIdHandler (CorrelationId.HttpClient) is internal #121

Open
bensmith009988 opened this issue Jan 16, 2025 · 0 comments
Open

CorrelationIdHandler (CorrelationId.HttpClient) is internal #121

bensmith009988 opened this issue Jan 16, 2025 · 0 comments

Comments

@bensmith009988
Copy link

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:

  1. 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)

  1. 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)

  1. 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)

  1. 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)

  1. 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.

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

No branches or pull requests

1 participant