What?
On a relationship field, set the filter to exists → True, then switch the operator to equals without touching the value. The list view goes blank. The URL ends up with where[or][0][and][0][authors][equals]=true, and on Postgres the server throws:
params: version.authors,true,NaN,10
error: invalid input syntax for type integer: "NaN"
If you go straight to Authors → equals and pick a user, it works fine. So it's the value carried over from exists that does it.
Why?
I think this is what #10648 was about. #11136 closed that one by resetting the value when the new operator can't take it, but keeping it when it can, so flipping between equals and not_equals doesn't wipe what you typed.
The catch is in getOperatorValueTypes. equals is 'any', and exists stores its value as the string 'true' / 'false' (there's a comment about that in validOperators), so the leftover 'true' passes as a valid value for equals. The check only looks at the operator you're switching to, so it has no idea the value came from exists. On a relationship field that string then gets cast for the integer id, comes out as NaN, and Postgres rejects it.
Same on 3.90.1, which was the latest when I checked. I ran into it on 3.87.1 in a real project and then reproduced it on a blank template.
The repro has drafts on, which is why the failing query hits _posts_v, and I haven't tried it without them. Also only tested on Postgres, so no idea what Mongo does.
How?
Same rule as #11136: only reset when the value stops making sense. A value that came from exists doesn't make sense for any other operator, so reset it. equals / not_equals / in would keep their value like they do now. Haven't checked whether other operator pairs have the same problem.
@jacobsfletch @JessRynkar was equals: 'any' meant to cover this, or did exists just not get thought of as a starting point? If it's a bug I'll open a PR.
Reproduction
Repo: https://github.com/rishabhmehta/payload-filter-repro
pnpm install, point DATABASE_URL at a Postgres db, pnpm dev, create two users.
- Posts → Filters → Add Filter.
- Authors,
exists, True.
- Switch the operator to
equals.
List view goes blank and the server logs invalid input syntax for type integer: "NaN".
Areas: area: ui, db: postgres
Environment: Payload 3.90.1, @payloadcms/db-postgres 3.90.1, Next 16.3.3, Node v24.11.1, pnpm 10.33.2, macOS 26.5.2
What?
On a relationship field, set the filter to
exists→ True, then switch the operator toequalswithout touching the value. The list view goes blank. The URL ends up withwhere[or][0][and][0][authors][equals]=true, and on Postgres the server throws:If you go straight to Authors → equals and pick a user, it works fine. So it's the value carried over from
existsthat does it.Why?
I think this is what #10648 was about. #11136 closed that one by resetting the value when the new operator can't take it, but keeping it when it can, so flipping between
equalsandnot_equalsdoesn't wipe what you typed.The catch is in
getOperatorValueTypes.equalsis'any', andexistsstores its value as the string'true'/'false'(there's a comment about that invalidOperators), so the leftover'true'passes as a valid value forequals. The check only looks at the operator you're switching to, so it has no idea the value came fromexists. On a relationship field that string then gets cast for the integer id, comes out as NaN, and Postgres rejects it.Same on 3.90.1, which was the latest when I checked. I ran into it on 3.87.1 in a real project and then reproduced it on a blank template.
The repro has drafts on, which is why the failing query hits
_posts_v, and I haven't tried it without them. Also only tested on Postgres, so no idea what Mongo does.How?
Same rule as #11136: only reset when the value stops making sense. A value that came from
existsdoesn't make sense for any other operator, so reset it.equals/not_equals/inwould keep their value like they do now. Haven't checked whether other operator pairs have the same problem.@jacobsfletch @JessRynkar was
equals: 'any'meant to cover this, or didexistsjust not get thought of as a starting point? If it's a bug I'll open a PR.Reproduction
Repo: https://github.com/rishabhmehta/payload-filter-repro
pnpm install, pointDATABASE_URLat a Postgres db,pnpm dev, create two users.exists, True.equals.List view goes blank and the server logs
invalid input syntax for type integer: "NaN".Areas:
area: ui,db: postgresEnvironment: Payload 3.90.1,
@payloadcms/db-postgres3.90.1, Next 16.3.3, Node v24.11.1, pnpm 10.33.2, macOS 26.5.2