How can I switch from the Consul node address to the service address to construct the downstream URL in versions 23.3 and later?

[Shachargi]

Title: Regression in Ocelot.Provider.Consul - Downstream URL uses Consul node address instead of service address after v23.2.2

Describe the bug

When using Ocelot.Provider.Consul version higher than 23.2.2, Ocelot starts resolving the downstream URL using the Consul node address instead of the actual service address registered in Consul. This causes downstream requests to be misrouted or fail completely.

This behavior does not occur in version 23.2.2, where the downstream URL is correctly constructed using the registered service address.

To Reproduce

1. Register a service in Consul (e.g., orderservice) with a custom address (not the node address).
2. Configure Ocelot to use the ServiceDiscoveryProvider with type Consul.
3. Define a route in ocelot.json using "ServiceName": "orderservice".
4. Use Ocelot.Provider.Consul version > 23.2.2.
5. Make a request through Ocelot.

Expected behavior

Ocelot should construct the downstream URL using the address and port of the service instance registered in Consul (i.e., from ServiceEntry.Service.Address and ServiceEntry.Service.Port), not the node address.

Actual behavior

The downstream URL is constructed using the node address (ServiceEntry.Node.Address), which can result in routing to the wrong host.

Version details

• Ocelot: 23.4.3
• Ocelot.Provider.Consul: > 23.2.2 (e.g., 23.3.0, 24.0.0)
• Works correctly in: 23.2.2
• Consul: 1.21.1
• .NET: 8.0

Additional context

This looks like a regression introduced after 23.2.2. Possibly related to a change in how service discovery entries are parsed or selected.

[raman-m]

Title: Regression in Ocelot.Provider.Consul - Downstream URL uses Consul node address instead of service address after v23.2.2

I don't think so!
Have you read official documentation sections? →

• Consul Service Builder explains the evolution of the feature and the DevOps challenges that may arise.
  The quote:

  Since version 13.5.2, the process for constructing the downstream host and port in pull request 909 has been changed to prioritize the node name as the host over the agent service address IP. This may raise some criticism from the community.

  To have a control over this longstanding Consul config & DevOps issues, version 23.3 introduced a customization feature that allows control over the service-building process ❕

• AddConsul<T> method solves the problem by writing a small class to be replaced in the DI-container. Are you able to write C# code?

Finally, I would say that version 13.5.2 introduced a "regression" where the node name takes precedence over the agent address.
In version 23.3.0, we aimed to preserve the previous behavior in the following method, where the node name still takes precedence over the agent address, ensuring no regression:

Ocelot/src/Ocelot.Provider.Consul/DefaultConsulServiceBuilder.cs

Lines 76 to 77 in 0b794b3

	protected virtual Node GetNode(ServiceEntry entry, Node[] nodes)
	=> entry?.Node ?? nodes?.FirstOrDefault(n => n.Address == entry?.Service?.Address);

Note: If you want to disable the "node name" feature entirely, simply refrain from defining both the entry node and nodes. After that, the service agent address will be used.
If it is impossible to remove node definitions from the Consul configuration, you must override this method to always return a null result, like this:

protected override Node GetNode(ServiceEntry entry, Node[] nodes) => null;

After that, the following method will always select and return the agent address, as the node name will always be null:

Ocelot/src/Ocelot.Provider.Consul/DefaultConsulServiceBuilder.cs

Lines 96 to 97 in 0b794b3

	protected virtual string GetDownstreamHost(ServiceEntry entry, Node node)
	=> node != null ? node.Name : entry.Service.Address;

Or simply override the GetDownstreamHost method following the documentation.

[raman-m]

Official answer

[raman-m]

Describe the bug

When using Ocelot.Provider.Consul version higher than 23.2.2, Ocelot starts resolving the downstream URL using the Consul node address instead of the actual service address registered in Consul. This causes downstream requests to be misrouted or fail completely.

In my opinion, there is no bug; the issue lies in differing DevOps strategies.
Please note that a minor change in the Consul configuration can result in behavior on Ocelot's side.
Could you explain the difference between "node address" and "service address"? I believe we should exclusively use the terms "node hostname" and "agent address" (service address), and nothing more because of current implementation of default builder.

This behavior does not occur in version 23.2.2, where the downstream URL is correctly constructed using the registered service address.

I expect some debate here... Could you attach the Consul configuration as plain text or a JSON file so we can continue analyzing the changes in the migration from 23.2.2 to 23.3.0?
So, only a real configuration will help here...

[raman-m]

To Reproduce

1. Register a service in Consul (e.g., orderservice) with a custom address (not the node address).
2. Configure Ocelot to use the ServiceDiscoveryProvider with type Consul.
3. Define a route in ocelot.json using "ServiceName": "orderservice".
4. Use Ocelot.Provider.Consul version > 23.2.2.
5. Make a request through Ocelot.

I guess a real Ocelot config (aka "ocelot.json") and real Consul config will help to "repro" your scenario.
These Steps to Repro are inefficient way to determine a bug.

[raman-m]

Expected behavior

Ocelot should construct the downstream URL using the address and port of the service instance registered in Consul (i.e., from ServiceEntry.Service.Address and ServiceEntry.Service.Port), not the node address.

It has already been implemented, mister!
Simply avoid defining nodes on Consul side, and you won’t even need to write any C# code.

---

Actual behavior

The downstream URL is constructed using the node address (ServiceEntry.Node.Address), which can result in routing to the wrong host.

Yes, because you define nodes.
Please read official Consul provider documentation to understand feature usage better.

[raman-m]

Version details

• Ocelot: 23.4.3
• Ocelot.Provider.Consul: > 23.2.2 (e.g., 23.3.0, 24.0.0)
• Works correctly in: 23.2.2
• Consul: 1.21.1
• .NET: 8.0

No, No ❗
All versions must match! So, you must upgrade all packages to v24.0.0 only (see Assets of the release notes). So, Ocelot and Consul provider versions must be the same!

[raman-m]

Additional context

This looks like a regression introduced after 23.2.2. Possibly related to a change in how service discovery entries are parsed or selected.

It looks like you don't read →

• official documentation: Consul Service Builder
• release notes: 23.3.0 → What's new? → Service Discovery

Yes, parsing and retrieving Consul data have been slightly modified, incorporating it into the DefaultConsulServiceBuilder and Consul classes. However, while parsing has changed, the overall functionality remains the same.

You need to understand the current implementation of the default service builder and leverage its flexible functionality, which supports overrides and customizations.
Additionally, be aware that a simple installation of the Consul service with the default Consul configuration and default Ocelot setup may not work as expected. Therefore, you will need to invest more time in configuring Consul for DevOps, fine-tuning Ocelot, and even handling Consul configuration through C# development.
Good luck!

[Shachargi]

Hey,
Thanks for referring me to the documentation.
I was not aware of the changes made in version 23.3.0.
And this was the first time I used the built-in load Balancer (round robin) until now i wrote custom load balancer which used explicitly the service address.
I updated all the Nuget to the latest version and added the override to the DefaultConsulServiceBuilder to use the Service.Address and everything works as expected.