fail: Wolverine.Runtime.WolverineRuntime[0]
Unexpected failure
System.NotSupportedException: The CLR type Wolverine.Envelope isn't natively supported by Npgsql or your PostgreSQL. To use it with a PostgreSQL composite you need to specify DataTypeName or to map it, please refer to the documentation.
at Npgsql.TypeMapping.TypeMapper.ResolveByClrType(Type type)
at Npgsql.TypeMapping.TypeMapper.ResolveByClrType(Type type)
at Npgsql.NpgsqlParameter.ResolveHandler(TypeMapper typeMapper)
at Npgsql.NpgsqlParameterCollection.ProcessParameters(TypeMapper typeMapper, Boolean validateValues, CommandType commandType)
at Npgsql.NpgsqlCommand.ExecuteReader(CommandBehavior behavior, Boolean async, CancellationToken cancellationToken)
at Npgsql.NpgsqlCommand.ExecuteReader(CommandBehavior behavior, Boolean async, CancellationToken cancellationToken)
at Npgsql.NpgsqlCommand.ExecuteNonQuery(Boolean async, CancellationToken cancellationToken)
at Weasel.Core.CommandExtensions.ExecuteOnce(DbCommand command, CancellationToken cancellation)
at Weasel.Core.CommandExtensions.ExecuteOnce(DbCommand command, CancellationToken cancellation)
at Wolverine.Persistence.Durability.DurableSendingAgent.<>c__DisplayClass14_0.<<enqueueForRetryAsync>b__4>d.MoveNext() in /home/runner/work/wolverine/wolverine/src/Wolverine/Persistence/Durability/DurableSendingAgent.cs:line 98Envelope directly in as a parameter
There are quite few SQL Server tests that are failing due to this error:
A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - Unknown error 1473249712)This is due to OpenSSL security level 2 being enabled by default on Ubuntu 20.04 and later:
https://learn.microsoft.com/en-us/sql/linux/sql-server-linux-encrypted-connections?view=sql-server-ver16#ubuntu-2004-and-other-recent-linux-distribution-releases
Hi. I've been giving Wolverine a try. If I understand correctly, if the original sender requested a reply, the cascading message will be sent to the sender and not to any other handlers.
In the below example, the IssueCreated message will be returned to the caller and will not be processed by another other handlers.
app.MapPost("/issues/create", (CreateIssue body, IMessageBus bus) => bus.InvokeAsync<IssueCreated>(body))As in the above example, is there a way to have the message be returned to the caller AND be processed by and registered handlers?
This would be useful for scenarios where the new issue id needs to be returned to the user while also allowing any background processes to react to the new issue.
Is there a slick way to observe Postgres inserts and bridge that on over to Wolverine? My scenario is using a Azure Logic App to capture a webhook, and then inject that directly to a table. (So it doesn't use a web api).
Also, I'm just using local queues for now. So not ASB or Rabbit. (I've solved this that way before)
var dbType = DetermineDbContextType(chain, container);
chain.Middleware.Insert(0, new EnrollDbContextInTransaction(dbType));
var saveChangesAsync =
dbType.GetMethod(nameof(DbContext.SaveChangesAsync), new[] { typeof(CancellationToken) });
var call = new MethodCall(dbType, saveChangesAsync)
{
CommentText = "Added by EF Core Transaction Middleware"
};
chain.Postprocessors.Add(call);
if (chain.ShouldFlushOutgoingMessages())
{
#pragma warning disable CS4014
chain.Postprocessors.Add(MethodCall.For<MessageContext>(x => x.FlushOutgoingMessagesAsync()));
#pragma warning restore CS4014
}DbContext.SaveChangesAsync() is definitely there and gets applied regardless. The chain.ShouldFlushOutgoingMessages() is a vestigal organ leftover from the very early days of Jasper when it was going to be both a message bus and an alternative HTTP AI tool, so it should even matter here. The FlushOutgoingMessagesAsync() is called internally by Wolverine outside of the generated code.
dotnet run -- codegen preview and see what code is geting spit out? There is actually an Alba test on that sample code, and it just passed on my box (like that means anything). I've had other reports of EF Core transaction middleware not working, but no reproductions. I've got nothing.
[Fact]
public async Task run_through_the_handler()
{
using var host = await AlbaHost.For<Program>();
var name = Guid.NewGuid().ToString();
var tracked = await host.InvokeMessageAndWaitAsync(new CreateItemCommand { Name = name });
tracked.FindSingleTrackedMessageOfType<ItemCreated>()
.ShouldNotBeNull();
using var nested = host.Services.As<IContainer>().GetNestedContainer();
var context = nested.GetInstance<ItemsDbContext>();
var item = context.Items.FirstOrDefaultAsync(x => x.Name == name);
item.ShouldNotBeNull();
}await for the query to see if an Item was added with the right name
3 replies
Hi, I might need a hint about how to bind a single RabbitMQ queue with 2 topic-patterns to the a single topic exchange.
More or less the situation shown in the topics RabbitMQ tutorial https://www.rabbitmq.com/tutorials/tutorial-five-python.html
I'm experiencing that only a single binding - the first one - is being created.
The sample at https://wolverine.netlify.app/guide/messaging/transports/rabbitmq.html#snippet-sample_binding_topics_and_topic_patterns_to_queues shows the same behavior.
It can be reproduced by adding e.g. exchange.BindTopic("color.cyan").ToQueue("blue"); as shown below.
theSender = Host.CreateDefaultBuilder()
.UseWolverine(opts =>
{
opts.UseRabbitMq().AutoProvision();
opts.PublishAllMessages().ToRabbitTopics("wolverine.topics", exchange =>
{
exchange.BindTopic("color.green").ToQueue("green");
exchange.BindTopic("color.blue").ToQueue("blue");
exchange.BindTopic("color.cyan").ToQueue("blue"); // <<< This binding does not get created
exchange.BindTopic("color.*").ToQueue("all");
});
}).Start();At first glance I was thinking whether below line of code might be involved
https://github.com/JasperFx/wolverine/blob/main/src/Transports/Wolverine.RabbitMQ/Internal/RabbitMqExchange.cs#L58