Neon•2y ago

absent-sapphire

Duplicated operation errors persist

Hey all, We're still seeing this when firing up our app on dev:

"Connection failed: {"errors":[{"errorType":"DuplicatedOperationError","message":"Duplicated operation with id 208aefd7-0597-48db-90a0-0bd4b5c8b0ae"}]}"

"Connection failed: {"errors":[{"errorType":"DuplicatedOperationError","message":"Duplicated operation with id 208aefd7-0597-48db-90a0-0bd4b5c8b0ae"}]}"

Once the database is "warmed up," this seems to go away. But we're concerned about this happening in production during lulls in activity. At this point, we're considering not using Neon because we don't have full confidence in it, and we really need to move forward with getting off of Aurora Serverless v1. I hope someone can help us look into this!

21 Replies

absent-sapphireOP•2y ago

this is how we're currently initializing and using Neon:

import { Config } from 'sst/node/config';
import { neon, neonConfig } from '@neondatabase/serverless';

neonConfig.fetchConnectionCache = true;

const sql = neon(Config.DATABASE_URL);

export const queryDb = async <T = any>(query: string) =>
  sql(query) as Promise<T[]>;

export const queryDbTransaction = (queries: string[]): Promise<any[][]> =>
  sql.transaction(queries.map(query => sql(query)));

import { Config } from 'sst/node/config';
import { neon, neonConfig } from '@neondatabase/serverless';

neonConfig.fetchConnectionCache = true;

const sql = neon(Config.DATABASE_URL);

export const queryDb = async <T = any>(query: string) =>
  sql(query) as Promise<T[]>;

export const queryDbTransaction = (queries: string[]): Promise<any[][]> =>
  sql.transaction(queries.map(query => sql(query)));

eastern-cyan•2y ago

Not sure if tyhis has anythign to do with it, but you shoud be able to drop: neonConfig.fetchConnectionCache = true That's now enabled by default in the Neon proxy. @Conrad Ludgate Any suggestions for this Duplicated operation error?

generous-apricot•2y ago

That's a new one to me

absent-sapphireOP•2y ago

it only seems to happen when we're firing up our dev instance for the day. so it has something to do with maybe Neon spinning up? not really sure. I just know we can't go into production with this

generous-apricot•2y ago

Where exactly do you see the error? Because it's not one that I would expect would be returned on sql query (I didn't see it in any of our logs, and we log all observable errors)

absent-sapphireOP•2y ago

it was shown in the browser console. which means it was likely thrown from the back end in response to a GraphQL query I'll have to wait till it happens again to dig any deeper. but if you want me to add any logging or troubleshooting steps, lemme know

generous-apricot•2y ago

Graphql makes sense. @Daniel noticed it mentioned in relation to AppSync

absent-sapphireOP•2y ago

but under the hood, it's nothing special going on. just a DB query via the @neondatabase/serverless package I'll see if I can maybe look for more details next time this happens. we'd really love to use Neon (it's production-ready at this point, right? last I checked, it hadn't reached general release)

fair-rose•2y ago

@Sam Hulick yep, we have folks using it in production. We are going GA very soon. It would be good to get more logs from the backend. For example, is an operation timing out due to a Neon cold start? Are you able to turn off Neon's auto suspend (just for your main branch) to see if it resolves the issue?

absent-sapphireOP•2y ago

lemme do some more detailed troubleshooting and I'll report back! BTW, shoud I be using the pooled connection for AWS Lambda? I'm not currently (at the time, it was recommended that I not use it)

fair-rose•2y ago

There were issues with the pooler endpoints and Prisma in the past. That might be why it was recommended to avoid it? Using the pooler URL is advised in edge/serverless environments.

absent-sapphireOP•2y ago

I don't recall exactly. Mahmoud would know (he's the one who suggested not using the pooler) I'll change the DB URL gotta wait for the DB to suspend. it's definitely taking longer than 5 mins, which is odd (it's upon DB spin-up that the issue occurs)

absent-sapphireOP•2y ago

so.. this is strange, no? it's 6:49pm here now. DB hasn't suspended, but the back end is definitely shut down

absent-sapphireOP•2y ago

in the past, it looks like it's taken anywhere from 30 to 60 minutes to suspend. but I have it set to suspend after 5 minutes

fair-rose•2y ago

Odd. Is your application potentially “pinging” it and keeping the database awake? I’ve not seen suspend fail before, but that doesn’t mean there’s not an issue on the neon side

absent-sapphireOP•2y ago

no, not that I'm aware of. wow, it took 3 hours 😕

absent-sapphireOP•2y ago

ok, now that it's spun down.. time to see if I can get a more detailed error when our app fires up! one sec maybe I'll not even use the web app.. rather, I'll use a GraphQL client to just make a query. just to simplify things ok! I think we can rule this out as an issue. 😅 not sure if it was changing to using pooled connections, or some other front-end issue interfering. from a cold start, Neon works perfectly fine. @ShinyPokemon @Conrad Ludgate @Daniel I appreciate your time with this! sorry it turned out to be a false alarm it is strange that it only happens when Neon is spun down. but.. there's some Amplify/GraphQL thing that I think is the core of the issue

absent-sapphireOP•2y ago

something to do with subscriptions.

absent-sapphireOP•2y ago

check out that trace

fair-rose•2y ago

Fantastic! Such are the joys of software development

absent-sapphireOP•2y ago

indeed 😄 which of the 100 things in these frameworks is the root cause? 😵‍💫 closing this thread. thanks again!

Gaming

Programming

Duplicated operation errors persist

Did you find this page helpful?