Is there a pending Autosave issue - does someone elese also have these issues?
#Error something went wrong on publishing and saving
hazy mason
tribal oakBOT
gentle plaza
Can you provide some more info about your project? Are you using one of our templates?
hazy mason
Next.js 16.2.3 + PayloadCMS 3.82.1 + React 19.2.4,
MongoDB/Mongoose adapter. Payloadcms website template — custom
project with ~8 collections (Pages, Projects, Products, Jobs,
Media, Team, etc.), most using drafts + autosave.
Symptom: Intermittent "Something went wrong" errors on
publish/save in the admin UI. Happens most reliably on
documents that are actively being autosaved while a user hits
Save/Publish, or when multiple PATCH requests to the same doc
overlap.
Root cause (what I traced it to): A race condition in
Payload's update flow where concurrent PATCHes on the same
document hit a forEach over a field/block array that has
become null/undefined mid-operation. The null-guard is missing
upstream, so the request throws instead of gracefully
handling the concurrent write.
Repro: I have a minimal reproduction repo ready
(payload-concurrent-patch-foreach-race) that triggers it
reliably by firing overlapping PATCH requests against a
collection with drafts + autosave + array/blocks fields. Happy
to share / file the issue if useful.
Current workaround: Disabled autosave on all 8 collections
(branch fix/disable-autosave-pages-projects). Errors stopped
immediately. Not ideal for editor UX, but stable.
@gentle plaza
hazy mason
What it is: PayloadCMS 3.83.0 has an unguarded Array.forEach in internal field traversal
(packages/payload/src/fields/hooks/beforeChange/promise.ts ~line 135). When two PATCHes race, the merged working state briefly
contains an undefined array entry, and the forEach dereferences it. Field name varies by code path — you've seen 'alt',
'blockType', '_status', now 'title'. Same root cause.
Why it fires on Pages now (autosave is off): Autosave was the main concurrency source, but not the only one. The race can still
be triggered by:
- Rapid manual Save-button clicks
- Nested-docs resaveChildren cascades on publish
- Live-preview refreshes
- Tab refocus / form resubmits
gentle plaza
Can you open an issue on GitHub for this? Thanks for the detailed writeup!!
hazy mason
@gentle plaza okey will do, is the repro repo really needed? dont have the time currently 😰
terse abyss
@gentle plaza we are having this issue to a debilitating degree in production and I don't even know what to put in an issue on GitHub because we can ONLY reproduce it on Vercel in our production environment for some reason. Not even our staging environment. But it will always say:
- Cannot read properties of undefined (reading 'lastPublishedAt')
- Cannot read properties of undefined (reading '_status')
- Cannot read properties of undefined (reading '_type')
It happens with autosave randomly, it happens on actual saves randomly. Sometimes it happens 90% of the time, sometimes it can be as low as 10% and it is seemingly without any rhyme or reason.
I have gone obsessive with logging an error handling to a psychotic degree anywhere that this can possibly be happening on my end and I can't get any closer.
I even made a contribution last week trying to fix where I thought this was happening, and it didn't solve the problem, it just resulted in more of these 2 errors:
- Cannot read properties of undefined (reading 'lastPublishedAt')
- Cannot read properties of undefined (reading '_status')
Where previously they were swallowed.
We have gone as far as completely overhauling our pooling logic, but we have it so bad because we defer cascades of dozens of operations into next/server after() hooks and use SSG/ISR to an unusual degree.
hazy mason
@terse abyss @gentle plaza exactkly the same issue for me. Only on vercel
terse abyss
I'll tell you what I did that seems to have worked for us, but it's definitely a payload bug. I went through every single hook in the entire project. Collection hooks, field hooks, etc, and operate under the assumption that every single doc, siblingDoc, context object, and req.payload reference, and operate in a way where you assume they will just randomly be undefined sometimes. Throw "?." everywhere, add try/catch blocks everywhere, Even in places it seems unnecessary or nonsensical.
Wrap the contents of every after() hook in try/catch. Crank up your Database pool connection count to 75 in production, and add rate limiting for any functions you offload into next/server.after().
Do not assume that route guards with autosave will be respected, Make sure that all of your autosave detection logic is using query parameter parsing, and don't assume it's always going to show up. I'm getting autosaves that aren't showing up with that query parameter, so just make sure you don't have critical logic associated with that.
I know some of that seems nonsensical but I did all of that out of desperation after 3 weeks of making no progress and finally yesterday we got it working
Also, to be clear, those solved two very different problems for me. The database connection pooling fixed and issue I was getting with no error message. When my database pools were exhausted. It was extremely hard to track that down especially considering that 3 weeks ago I didn't have the same trouble even with the same logic.
The obsessive error handling on every possible reference in every single hook is what eventually made the app usable again
hazy mason
@terse abyss oh my god and i thought i was the only one having these issues and that i implemented the error somewhere...
@terse abyss what db are you using?
i can tell you i wasted so many hours debugging and researching. i ended up disabling auto save and just work with normal save... this seemed to somehow work a bit better for me
but also i got the same pooling error message but i didnt thought about it comming from this 😮
@terse abyss are you also on next 16.x?
gentle plaza
Hey guys, sorry I've been traveling the past couple of days. Looking into this now. I ran into this myself, and I'm not sure how I fixed it, or if I did. I'll report back shortly!
gentle plaza
Ok, so I am remembering this behavior exactly now and as @terse abyss mentioned, the root cause is connection pool exhaustion. I was connected to my prod DB locally and updating docs on my live site, so my connections spiked massivlely and I couldn't save anything. Is your Atlas cluster on the free tier? (M0) That has a limit of 500 connections and that can get up there pretty quick
terse abyss
<@709491249777737738> what db are you using?
Postgres
hazy mason
im using mongodb atlas
terse abyss
Ok, so I am remembering this behavior exactly now and as <@709491249777737738> m...
Well, this is 1 of 2 things, I solved that problem and that didn't solve it entirely. I wrote some fairly sophisticated queue logic that works very well to ensure connections are available but I was still ending up with empty doc and siblingDoc values in my various hooks. I think that some concurrent operations can fire while a document is locked, and Payload doesn't have enough protections in place to stop undefined from being pased in
terse abyss
<@709491249777737738> are you also on next 16.x?
Yes, I'm on 16.2.4
hazy mason
okey how do we move on from here? Can we gather some informtions and file a issue together? @terse abyss @gentle plaza Funny that there are not more people sharing the same issues
i think it could have to do something with next 16
terse abyss
They're aware and looking into it