Nservicebus: ATTs framework restricts endpoint name length

[SeanFeldman]

ATTs packaged with Core need to be executed with any supported transport. For this reason, there's a cap in place on the length of endpoints. Unfortunately, this also imposes a limitation on the ATTs that are added at transport level with intention to have endpoint names longer than the imposed maximum (77 characters).

System.Exception : Endpoint name 'SendingMessageWithHierarchyCompositionStrategy.SourceEndpoint_veeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeerrrrrrrrrrrrrrrrrrrrrrryyyyyyyyyyyyyyyyyyyllllllllllllllllllllloooooooooooooooooooonnnnnnnnnnnnnnnnnnggggggggggggg_qqqqqqqqqqqqqqquuuuuuuuuuuuueeeeeeeennnnnnnnnnnnnnnnnaaaaaaaaaaaaaammmmmmmmmmmmmmmmmmmmmmmeeeeeeeeeeee' is larger than 77 characters and will cause issues with MSMQ queue names. Rename the test class or endpoint.

Transport that can support more than 77 characters with tests that are added at the transport ATTs level should be able to override/remove this restriction.

[timbussmann]

I think we should keep that constraint to prevent long queue names to cause issues in downstreams, but maybe adding an option to disable those checks would be helpful for @SeanFeldman use case.

[bording]

Ideally, this feels like something to expose through the TestSuiteConstraints, but since that's not actually a framework concept, I don't think we have a way to do that.

[andreasohlund]

Don't we want to turn this off for a few selected tests? So some kind of option to .SkipMaxQueueLengthValidation() ?

[bording]

I suppose we could do that, but either you're running on a transport that has a limitation, or you aren't. Not sure there's a point to always enforcing something when it's only a problem for one transport. For example, consider how we just removed the NHibernate-specific enforcement from the tests package.

Alternatively, if there are different, larger length limits, it seems like being able to customize the length value could be a way to go as well.

[SeanFeldman]

I like what @andreasohlund. Relaxing/removing length restriction would be a test specific thing. I.e. case by case for ATTs outside of Core provided tests.

[andreasohlund]

@bording I think you might be on to something, what if we removed the lenght checks from the runtime parts but instead added a "SelfVerification" test similar to https://github.com/Particular/NServiceBus/blob/develop/src/NServiceBus.AcceptanceTests/SelfVerification/When_running_saga_tests.cs#L13

This means that we can't add endpoints that generates to long queue names in the tests we ship but since we don't ship the verifications since they are in the core folder all downstreams are free to do what they like.

Thoughts?

[timbussmann]

Ideally, this feels like something to expose through the TestSuiteConstraints, but since that's not actually a framework concept, I don't think we have a way to do that.

sounds like this should be defined in the transport definition and then be read by the testing framework. That's valuable information for a real endpoint as well?

[bording]

@andreasohlund If we can come up with a test that can verify that, then that seems like the easiest way forward for now. Add that test and remove the check from the framework.

@timbussmann Adding something the transport seam to report that kind of information does seem like it could useful in the long term, and not just for testing. Core could also use it for validation as well.

[andreasohlund]

If we can come up with a test that can verify that, then that seems like the easiest way forward for now. Add that test and remove the check from the framework.

Agreed, the main thing here is to make sure that we don't ship tests with to long names for downstreams and this would solve this nicely

[timbussmann]

I've raised a core issue for the proposed workaround: https://github.com/Particular/NServiceBus/issues/5105 and a dedicated issue for potential transport seam API changes in the pdev repo based on the conversation in this issue. I'd propose to close this issue therefore. Thoughts @SeanFeldman ?

[SeanFeldman]

👍