26000: prepared statement "_auto2" does not exist

Steps to reproduce

non yet, unfortunately

The issue

After upgrading to latest npgsql/ef.core 3.1.1.1 and npgsql to 4.1.3 these errors started to appear. Nothing relevant changed in the code base except for that update and updating FluentAssertions (which is only used in unit test projects, so it shouldn’t have an effect)

When running our e2e tests we see on ~every second run, maybe 2 out of 3 the error:

26000: prepared statement "_auto2" does not exist

as far as I could see, it was always _auto2 (from 10 different checks) pointing to either a command or a query, but always the same one. Before we start running the tests (which can execute in a random order), we do have a setup procedure which is always executed in the same order in parallel for 2 tenants. So that’s where _auto2 could always be initialized to the same query.

This is different from https://github.com/npgsql/npgsql/issues/2482 - I don’t recall ever seeing this before (although, it’s the same application)

Might be related to https://github.com/npgsql/npgsql/issues/2731 - we just switched to .net core 3 (3.1) last week. But given how persistent the error is right now, I doubt we’d have missed it last week.

Given, that we just use auto prepared statements with EF Core and never touch an npgsql connection directly, I don’t know how we could have caused this. One thing that we wrap some requests in a repeatable read transaction and retry it if it fails due to concurrent update issues. In order to be able to retry it properly, we have to clean the EF Core with their internal method:

        private void ClearChangeTracker()
        {
            var me = (IDbContextPoolable)this;

            lock (me)
            {
                _acquiredLocks.Clear();

                me.ResetState();
#pragma warning disable EF1001
                me.Resurrect(me.SnapshotConfiguration());
#pragma warning restore EF1001
            }
        }

But that code exists already for 2 years, so hard to imagine that it would start breaking now.

Further technical details

Npgsql version: 4.1.3 (it did work in 4.1.2) PostgreSQL version: 11 Operating system: docker image FROM mcr.microsoft.com/dotnet/core/aspnet:3.1

[rpatrick00]

@roji Sorry, there was an error in my code where the parameter binding didn’t match the query string…

[pgrm]

In that case, is there any way you can try to not do that and confirm whether the issue still occurs?

good point - I’ll try that out, definitely easier than trying to reproduce the whole thing