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

Unhelpful exception message when clientProvidedName is too long #980

Closed
loop-evgeny opened this issue Nov 24, 2020 · 3 comments · Fixed by #1576
Closed

Unhelpful exception message when clientProvidedName is too long #980

loop-evgeny opened this issue Nov 24, 2020 · 3 comments · Fixed by #1576
Assignees
Milestone

Comments

@loop-evgeny
Copy link

loop-evgeny commented Nov 24, 2020

RabbitMQ .NET client 6.1.2 on .NET Core 3.1, Windows 7
RabbitMQ Server 3.7.26, Erlang 22.2.8, Ubuntu 18.04

Try to create a connection with a clientProvidedName that's too long, like this:

new ConnectionFactory {HostName = ..., UserName = ..., Password = ...}.CreateConnection(new string('x', 4000));

Expected results - either an exception message that tells me that the clientProvidedName is too long or the clientProvidedName is automatically truncated to a usable length. (The latter is probably preferable: as I understand, clientProvidedName is mostly used for troubleshooting, so most users would probably prefer for the connection to succeed.)

Actual results - exception message that gives little clue as to what's wrong:

 ---> RabbitMQ.Client.Exceptions.BrokerUnreachableException: None of the specified endpoints were reachable
 ---> RabbitMQ.Client.Exceptions.PossibleAuthenticationFailureException: Possibly caused by authentication failure
 ---> RabbitMQ.Client.Exceptions.OperationInterruptedException: The AMQP operation was interrupted: AMQP close-reason, initiated by Library, code=0, text='End of stream', classId=0, methodId=0, cause=System.IO.EndOfStreamException: Reached the end of the stream. Possible authentication failure.
   at RabbitMQ.Client.Impl.InboundFrame.ReadFrom(Stream reader, Byte[] frameHeaderBuffer)
   at RabbitMQ.Client.Impl.SocketFrameHandler.ReadFrame()
   at RabbitMQ.Client.Framing.Impl.Connection.MainLoopIteration()
   at RabbitMQ.Client.Framing.Impl.Connection.MainLoop()
   at RabbitMQ.Client.Impl.SimpleBlockingRpcContinuation.GetReply(TimeSpan timeout)
   at RabbitMQ.Client.Impl.ModelBase.ConnectionStartOk(IDictionary`2 clientProperties, String mechanism, Byte[] response, String locale)
   at RabbitMQ.Client.Framing.Impl.Connection.StartAndTune()
   --- End of inner exception stack trace ---
   at RabbitMQ.Client.Framing.Impl.Connection.StartAndTune()
   at RabbitMQ.Client.Framing.Impl.Connection.Open(Boolean insist)
   at RabbitMQ.Client.Framing.Impl.Connection..ctor(IConnectionFactory factory, Boolean insist, IFrameHandler frameHandler, String clientProvidedName)
   at RabbitMQ.Client.Framing.Impl.ProtocolBase.CreateConnection(IConnectionFactory factory, Boolean insist, IFrameHandler frameHandler, String clientProvidedName)
   at RabbitMQ.Client.ConnectionFactory.CreateConnection(IEndpointResolver endpointResolver, String clientProvidedName)
   --- End of inner exception stack trace ---
   at RabbitMQ.Client.ConnectionFactory.CreateConnection(IEndpointResolver endpointResolver, String clientProvidedName)
   at RabbitMQ.Client.ConnectionFactory.CreateConnection(String clientProvidedName)

The server logs this:

[error] <0.11030.332> closing AMQP connection <0.11030.332> (CLIENT_IP:CLIENT_PORT -> SERVER_IP:SERVER_PORT):
{handshake_error,starting,0,{amqp_error,frame_error,"type 1, all octets = <<>>: {frame_too_large,4368,4088}",none}}

... which is slightly more helpful - but not everyone has access to server logs.

@loop-evgeny loop-evgeny changed the title Misleading exception message when clientProvidedName is too long Unhelpful exception message when clientProvidedName is too long Nov 24, 2020
@michaelklishin
Copy link
Member

@loop-evgeny would you mind providing an example of a message that is "too long"?

Since this happens early during connection negotiation, the max frame size is not yet negotiated and so there is a default frame size that must be exceeded. Enforcing validation when the value is set is the only solution.

@loop-evgeny
Copy link
Author

If you mean what the client generates when I call CreateConnection - I don't know how to capture that. But it should be easy to repro the problem with the one-liner above.

@lukebakken lukebakken self-assigned this Jan 3, 2024
@lukebakken lukebakken added this to the 7.0.0 milestone Jan 3, 2024
lukebakken added a commit that referenced this issue May 23, 2024
lukebakken added a commit that referenced this issue May 23, 2024
@michaelklishin
Copy link
Member

If you mean what the client generates when I call CreateConnection - I don't know how to capture that. But it should be easy to repro the problem with the one-liner above.

Just FTR, with most clients the best way to capture that value is to take a traffic capture. With some (Bunny, possibly others) a tracing mode of all outgoing protocol frames would be an easier alternative.

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

Successfully merging a pull request may close this issue.

3 participants