Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
"This operation is only allowed using a successfully authenticated context"" #2593
We are trying to get to the bottom of what seems like an almost random occurrence of an exception. We are unable to, at the moment, get a reliable reproduction in our own code, nor on a small repro project.
The exception happens in
The issue does not happen at any particular place in our code, it can happen at any point when a query or command is being executed against Postgres.
The only thing we have been able to determine is it will happen more often if one part the request we have been testing takes a long time when connecting to another 3rd party (i.e. disable that service and reduce overall latency of a single request by ~10s and this becomes much harder, if not impossible, to reproduce).
If we put a breakpoint logging point in
Further technical details
Npgsql version: 4.0.9
This is indeed odd.
First, have you looked at the server-side PostgreSQL logs to see if any messages are logged around the failure time? That might provide some clues.
One thought is that perhaps the connection is simply lost/broken, and this is manifesting as an SSL/TLS issue (although it really isn't). If so, depending on the root cause you might be able to make it go away by turning on keepalive.
Finally, the only thing this brings to mind is the infamous SSL renegotiation feature, where the SSL stack would periodically initiate renegotiations. This feature has been disabled in PostgreSQL for quite a while, but can you please post exactly which server of PostgreSQL you're connecting to?
I've not looked at the PostgresSQL logs to help track this down, and TBH without looking not sure how much access Azure gives for the managed instances.
I do not have a reproduction, but I do believe I know what the issue was (at least sort of). We grabbed our connections from
We had one instance in an attribute that used a
The "3rd party taking a long time" bit was a red herring. We disabled the component, which happened to also remove the problematic instantiation and non-explicit disposal of a connection.
So, in short, this seems to manifest if you have connections being opened and closed correctly + a handful NOT being disposed of correctly (although I believe they would generally have been cleared up after a period of time as they were IDLE).
So whilst this was caused by poor usage of the API, the manifestation of it is very odd and definitely does not lead you down the right path. Not sure if this is something that could be improved on in the library? Either handling the exception and throwing a more detailed one with possible reasons, or by handling the connections that are not disposed of explictly differently?
BTW the Postgres server is an Azure managed instance, with the version string of
@barclayadam thanks for investigating and reporting back, good to hear it wasn't an issue in the driver itself.
Now that you understand exactly what happened, any chance you could post a small code sample which shows exactly how to reproduce this? Npgsql definitely does have some safeguards against incorrect user usage, but it's far from perfect and can indeed be improved.