Azure Service Bus CreateRule Exception #748
Comments
|
Thanks for raising this issue, @Lars-Kolsaker. In talking with a colleague, he made me notice that we explicitly guard against this from happening in the transport code. I'll try to reproduce the issue on my side to better understand what's going on. |
|
@Lars-Kolsaker, I did the following:
<PackageReference Include="NServiceBus.AzureFunctions.InProcess.ServiceBus" Version="4.2.0" />
<PackageReference Include="NServiceBus.Transport.AzureServiceBus" Version="3.2.1" />
public class SomethingHappened : IEvent
{
public string What { get; set; }
}
public async Task Handle(TriggerMessage message, IMessageHandlerContext context)
{
Log.Warn($"Handling {nameof(TriggerMessage)} in {nameof(TriggerMessageHandler)}");
Log.Warn($"Custom component returned: {customComponent.GetValue()}");
await context.SendLocal(new FollowupMessage());
await context.Publish(new SomethingHappened() { What = "Wow!"});
}
public class SomethingHappenedHandler : IHandleMessages<SomethingHappened>
{
static readonly ILog Log = LogManager.GetLogger<SomethingHappenedHandler>();
public Task Handle(SomethingHappened message, IMessageHandlerContext context)
{
Log.Warn($"Handling {nameof(SomethingHappened)} in {nameof(SomethingHappenedHandler)}: {message.What}.");
return Task.CompletedTask;
}
}Running the sample works as expected. I can inspect the
Running the sample more than once, which retries the rule creation, doesn't throw. Can you please try to do the same and see if you manage to make it fail similarly to what happens in your environment? |
|
One more thing, can you show me the definitions for the |
|
@mauroservienti sorry for late reply, but I did not got any notifications about your reply Have not any problem with using the sample application. Our application has been working for a while, but are now throwing this exception. Could be due to our configuration of the transport topology ref Sean Feldman comment in the discussion group You’re configuring the transport topology. This might be an issue if the transport assembly is picked up. |
|
And here is the definitions using Adp.Common.Models.DTO;
namespace Adp.Common.Messages.Mds;
// WARNING! Changed name will affect the NServiceBus subscription
public class ReceiveMessageMdsCompany : IReceiveMdsMessage<Company>
{
public string? MessageId { get; set; }
public AdpMessage<Company>? AdpMessage { get; set; }
}using Adp.Common.Models.DTO;
namespace Adp.Common.Messages.Mds;
// WARNING! Changed name will affect the NServiceBus subscription
public class ReceiveMessageMdsPerson : IReceiveMdsMessage<Person>
{
public string? MessageId { get; set; }
public AdpMessage<Person>? AdpMessage { get; set; }
}`using Adp.Common.Models.Enums;
using Newtonsoft.Json;
using Newtonsoft.Json.Converters;
namespace Adp.Common.Messages;
public class AdpMessage<T> where T : class
{
[JsonConverter(typeof(StringEnumConverter))]
public EntityType EntityType { get; set; }
[JsonConverter(typeof(StringEnumConverter))]
public ActionType Action { get; set; }
[JsonConverter(typeof(StringEnumConverter))]
public Source Source { get; set; }
[JsonConverter(typeof(StringEnumConverter))]
public Source OriginalSource { get; set; }
public T Data { get; set; }
}
public enum ActionType
{
Upsert = 0,
Delete = 2
}
public enum EntityType
{
Unknown = -1,
User = 0,
Company = 1,
Person = 2,
Unit = 3,
Customer = 4,
Location = 5
} |
|
@mauroservienti Any news on this? |
|
I made no progress. I'm still not able to reproduce the issue you're facing. And sorry for getting back to you late, I should have provided an update earlier. |
|
I forgot about adding that it has nothing to do with the custom topology. I ran the same sample using a custom topic name, which worked as expected. I suspect it might be related to inheritance and generics in the messages' definitions. I'll try to factor that in my example. |
|
@Lars-Kolsaker I added two messages with a polymorphic structure similar to yours to my example. It still works as expected without throwing any exceptions. I published the example on my GitHub account. Could you look at it and see if you can spot any difference in your environment? |
Describe the bug
Description
We have starting to receive the following exception in our logs. Not sure if this is a bug or is some misuse. Had a discussion on ParticularDiscussion (https://discuss.particular.net/t/createrule-exception/3774) and was recommend to raise an issue here.
This exception occurs when our function app receives a Service bus message in our implementation of the IMessageHandler (see start of code below).
Does NServicebus try to add a filter rule to the topic ?
Here is some traces from application insight that hints me that this initiated by NServiceBus
And here is part of our IMessageHandler implementation
And here is our startup with NserviceBus configuration
Expected behavior
Actual behavior
Versions
We are using the following NServiceBus components
NServiceBus.AzureFunctions.InProcess.ServiceBus 4.2.0
NServiceBus.Transport.AzureServiceBus 3.2.1
Steps to reproduce
See description above
Relevant log output
No response
Additional Information
Workarounds
Possible solutions
Additional information
The text was updated successfully, but these errors were encountered: