Exchange and Queue name length validation #649
Conversation
|
I'm not sure this the approach we should take for trying to solve #453. The catching of exceptions around the declarations I believe are still needed because there are other scenarios where those can through. I'm also not sure the length check you added will actually catch all scenarios for length problems. The underlying AMQP protocol allows for 255 bytes, not characters, so for UTF-8, that could result in fewer characters if they are multi-byte encoded. For the direct routing topology, there is still a missing scenario where the binding key can be too long. Based on all of this, I think we might just need to catch the exception and rethrow a friendlier exception. |
|
@bording the 6.x Rabbit Client removed the check (in The current behavior is that when a name gets encoded to more than 255 bytes the call will timeout on the client-side. Looking at the broker logs it seems that this is the client library issue. In summary, the client is no longer throwing an exception that we can "wrap". Secondly, in my opinion, the current behavior is even more confusing than previously. As a result, I'd rather do the check on our end. When it comes to
This check needs to be done whenever we do |
bording
force-pushed
the
entity-name-validation
branch
from
9cbed15 to
b5d93fc
Compare
This is definitely a bug that should be fixed in the client: rabbitmq/rabbitmq-dotnet-client#907 At this point, I'd like to get this fixed there vs. trying to work around it in the transport. Let's discuss what that means for this PR. |
|
@bording I agree that fixing that in the client is the best option. I think we should open a PR in the client. |
|
PR opened in the Rabbit Client rabbitmq/rabbitmq-dotnet-client#908 |
fixes #453