Invalid input {} instead of ID error when creating/updating a document with a localized media field.

[omaroubari]

Describe the Bug

Essentially creating or updating a document fails if it has a specific block type(s). When we first pushed to prod, the faulty blocks worked as expected - and saving and publishing was perfectly fine.

The error message from the logger says:

ERROR: invalid input syntax for type integer: "{}" err: { "type": "DatabaseError", "message": "invalid input syntax for type integer: \"{}\"", "stack": error: invalid input syntax for type integer: "{}" ..., "length": 140, "name": "error", "severity": "ERROR", "code": "22P02", "where": "unnamed portal parameter $1 = '...'", "file": "numutils.c", "line": "232", "routine": "pg_strtoint32" }

and from the database logs I can see it is related to an undefined id indeed: postgres15.8 | 2025-05-20 16:20:32.040 UTC [121] ERROR: invalid input syntax for type integer: "{}" postgres15.8 | 2025-05-20 16:20:32.040 UTC [121] CONTEXT: unnamed portal parameter $1 = '...' postgres15.8 | 2025-05-20 16:20:32.040 UTC [121] STATEMENT: insert into "callToActionBlock_locales" ("badge_label", "rich_text", "media_id", "id", "_locale", "_parent_id") values (default, default, $1, default, $2, $3), (default, default, $4, default, $5, $6) returning "badge_label", "rich_text", "media_id", "id", "_locale", "_parent_id" The error started randomly occurring in production and doesn't reproduce locally with a fresh database neither in dev or on a preview build. The only I could replicate it locally was through dumping the production database. It hasn't resolved

Looking at the erroneous blocks (Features and Call to action), which you can view in src/blocks, I'm guessing it might be related to the localized media fields present in their schema. Commenting out the localized:true in the 'blockImage' field in the 'Features' block for example resolves the create/update error. You would have to create a migration and run it to see that.

Please pardon me if the error description is wrong or if it turns out to be a mistake on my part. Thanks for looking into this.

Link to the code that reproduces this issue

https://github.com/agi-v0/payload/tree/bug

Reproduction Steps

1. Clone repo (ensure you're on the 'bug' branch).
2. run docker compose up to set up db.
3. Set up your .env based on env.example (copy the same DATABASE_URI)
4. run bash dump_to_local.sh
5. Launch dev server (turbopack works nicely if you prefer).
6. You should be able to auto signin into a user from the dumped database.
7. Go into any 'Pages' doc > go to 'Layout' > add a 'Features' block or a 'Call to Action' block and hit publish.
8. Remove any of those blocks and add any other ("Featured Apps" or "Gallery") - should work fine.

Optionally: 9. Comment out the localize: true prop of the blockImage field in the Features block, then create and run a migration, then refresh the admin panel and try adding a features block: should work fine.

Which area(s) are affected? (Select all that apply)

db-postgres, db-vercel-postgres

Environment Info

Binaries:
  Node: 22.14.0
  npm: 10.9.2
  Yarn: N/A
  pnpm: 10.6.5
Relevant Packages:
  payload: 3.38.0
  next: 15.3.2
  @payloadcms/db-postgres: 3.38.0
  @payloadcms/email-nodemailer: 3.38.0
  @payloadcms/email-resend: 3.38.0
  @payloadcms/graphql: 3.38.0
  @payloadcms/live-preview: 3.38.0
  @payloadcms/live-preview-react: 3.38.0
  @payloadcms/next/utilities: 3.38.0
  @payloadcms/payload-cloud: 3.38.0
  @payloadcms/plugin-cloud-storage: 3.38.0
  @payloadcms/plugin-form-builder: 3.38.0
  @payloadcms/plugin-nested-docs: 3.38.0
  @payloadcms/plugin-redirects: 3.38.0
  @payloadcms/plugin-search: 3.38.0
  @payloadcms/plugin-seo: 3.38.0
  @payloadcms/richtext-lexical: 3.38.0
  @payloadcms/storage-s3: 3.38.0
  @payloadcms/translations: 3.38.0
  @payloadcms/ui/shared: 3.38.0
  react: 19.1.0
  react-dom: 19.1.0
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.4.0: Fri Apr 11 18:32:50 PDT 2025; root:xnu-11417.101.15~117/RELEASE_ARM64_T6041
  Available memory (MB): 24576
  Available CPU cores: 12

[omaroubari]

It's worth noting that the hero schema also contains a localized media field but it isn't throwing any errors on create / publish.

[patriksimms]

I can confirm this issue. When setting up locales, our error message was a little different: invalid input syntax for type integer: "{"en":44,"de":null}".

In our case the issue came from the MetaImageField from @payloadcms/plugin-seo. When removing this field from the documents config, everything works fine.

This is how our Media collection looks like:

`import type { CollectionConfig } from 'payload'

export const Media: CollectionConfig = { slug: 'media', access: { read: () => true, }, fields: [ { name: 'alt', type: 'text', required: true, localized: true }, ], upload: true, } `

Edit: It seems that the pure existance of the MetaImageField in our FieldConfig for our posts is the problem. When I remove it, it works while still present in the Admin Interface

[danielkoller]

We're also experiencing this exact issue.

Environment:

• PayloadCMS: 3.51.0
• Database: PostgreSQL
• Next.js: 15.4.7

Error logs: ERROR: invalid input syntax for type integer: "{}" at unnamed portal parameter $3 = '...' File: numutils.c Line: 617 Routine: pg_strtoint32_safe

ERROR: Cannot read properties of undefined (reading 'title')

Affected configuration: { name: 'image', type: 'upload', localized: true, relationTo: 'media', required: true, }

Impact: Autosave fails when editing pages containing the ColoredCard block. The error occurs immediately when the block is added to a page, preventing users from saving their work.

Current workaround: We've removed localized: true from the upload field, but this limits our i18n capabilities.

This issue is critical for multilingual sites that need localized media assets. Looking forward to a fix!

[danielkoller]

I quickly tested it with the latest version. Still affected. Here is a repo to showcase the bug -> https://github.com/danielkoller/payload-cms-bug-relation-to

[6TELOIV]

As a workaround, have you tried using blocksAsJSON? The blocks would no longer exist in their own relationship table, and instead would be a JSONb field.

Of course, this doesn't mean the underlying bug should go unfixed; it certainly is an issue.

[danielkoller]

@6TELOIV thanks, the problem is that this nukes the content and we have about 30 pages where our editor would need to redo the content. So that is unfortunately not an option..

[6TELOIV]

Hmm, you could modify migration to move the relationship-based-blocks to jsonb-based-blocks. It wouldn't be easy, but it would be possible!

[omaroubari]

@6TELOIV I can't find anything about blocksAsJSON in the docs. Can you share how it is used?

[6TELOIV]

It is an option for the posgresql DB adapter.

Setting blocksAsJSON to true will store the blocks as a JSON column instead of a relationship table. This works around this issue because they don't have the unique ID constraint when they are just embedded data in a JSON column.

[omaroubari]

I see, thanks. I don't think this is an option at the moment as that is a huge workaround. I think it would make autosave slower for small edits as that would mean the entire JSON value will be sent every interval if I understand this correctly.

[danielkoller]

R1tsuu is aware of the problem. Lets just hope for a quick fix. :)

[github-actions[bot]]

🚀 This is included in version v3.57.0

[github-actions[bot]]

This issue has been automatically locked. Please open a new issue if this issue persists with any additional detail.