Open Lars-Kolsaker opened 7 months ago
mauroservienti
commented
6 months ago 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.
mauroservienti
commented
6 months ago @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" />AzureFunctions.Messages project by adding a new class that implements the IEvent interface:public class SomethingHappened : IEvent
{
public string What { get; set; }
}TriggerMessageHandler to publish the new event: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 bundle-1 and see the newly added rule:
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?
mauroservienti
commented
6 months ago One more thing, can you show me the definitions for the ReceiveMessageMdsCompany and ReceiveMessageMdsPerson event types?
Lars-Kolsaker
commented
6 months ago @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.
Lars-Kolsaker
commented
6 months ago 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?
mauroservienti
commented
5 months ago 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.
mauroservienti
commented
5 months ago 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.
mauroservienti
commented
5 months ago @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