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
In 1.7.14.4 when loading the the consul configuration from the environment variable CONSUL_HTTP_ADDR it does not parse the variable correctly when using a string based host name for the consul address.
In 1.7.14.3 the following example setting would parse properly as the host name and port:
CONSUL_HTTP_ADDR = consul:8500
In 1.7.14.4 this get's parsed out as:
Host is left default (127.0.0.1)
Path is set to 8500
Port is set to -1
This is caused by the Uri.TryCreate reading that string as:
Scheme is set to consul
AbsolutePath is set to 8500
Steps To Reproduce
Set your CONSUL_HTTP_ADDR to a DNS named consul server with port (consul:8500)
Set your CONSUL_HTTP_TOKEN to a valid token for that consul server
New up the ConsulClient object using the default constructor.
Fetch any items from the KV (await client.KV.List("anykey");)
Notice Exception:
Exception has occurred: CLR/System.Net.Http.HttpRequestException
An exception of type 'System.Net.Http.HttpRequestException' occurred in System.Private.CoreLib.dll but was not handled in user code: 'No connection could be made because the target machine actively refused it. (127.0.0.1:80)'
Inner exceptions found, see $exception in variables window for more details.
Innermost exception System.Net.Sockets.SocketException : No connection could be made because the target machine actively refused it.
at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)
at System.Net.Sockets.Socket.<g__WaitForConnectWithCancellation|285_0>d.MoveNext()
at System.Net.Http.HttpConnectionPool.d__104.MoveNext()
Expected behavior
Legacy URI parsing behavior for environment variables should be maintained or this should be called out as a breaking change in this version.
Environment
OS: Windows
Consul Version: 1.19.1
consultdotnet Version 1.7.14.4
Logs
No response
Additional context
No response
The text was updated successfully, but these errors were encountered:
tdeangelis
changed the title
[Bug]: Loading consul configuration from environment fails in 1.7.14.4
[Bug]: Loading consul configuration from environment variables fails in 1.7.14.4
Aug 22, 2024
Describe the bug
In 1.7.14.4 when loading the the consul configuration from the environment variable CONSUL_HTTP_ADDR it does not parse the variable correctly when using a string based host name for the consul address.
In 1.7.14.3 the following example setting would parse properly as the host name and port:
CONSUL_HTTP_ADDR = consul:8500
In 1.7.14.4 this get's parsed out as:
This is caused by the Uri.TryCreate reading that string as:
Steps To Reproduce
Exception has occurred: CLR/System.Net.Http.HttpRequestException
An exception of type 'System.Net.Http.HttpRequestException' occurred in System.Private.CoreLib.dll but was not handled in user code: 'No connection could be made because the target machine actively refused it. (127.0.0.1:80)'
Inner exceptions found, see $exception in variables window for more details.
Innermost exception System.Net.Sockets.SocketException : No connection could be made because the target machine actively refused it.
at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)
at System.Net.Sockets.Socket.<g__WaitForConnectWithCancellation|285_0>d.MoveNext()
at System.Net.Http.HttpConnectionPool.d__104.MoveNext()
Expected behavior
Legacy URI parsing behavior for environment variables should be maintained or this should be called out as a breaking change in this version.
Environment
Logs
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: