Field "unique: true" is not respected

[oysteinwangen]

Describe the Bug

Even though I add "unique: true" for a slug field, it is still possible to create two documents in the same collection with the same slug.

Link to the code that reproduces this issue

npx create-payload-app@latest -t website

Reproduction Steps

In /src/fields/slug/index.ts
Add unique: true under slugField.

Use mongodb.

Try to create two categories or posts with the same slug.

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

area: core

Environment Info

Binaries:
  Node: 23.7.0
  npm: 10.9.2
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  payload: 3.24.0
  next: 15.1.7
  @payloadcms/db-mongodb: 3.24.0
  @payloadcms/email-nodemailer: 3.24.0
  @payloadcms/graphql: 3.24.0
  @payloadcms/live-preview: 3.24.0
  @payloadcms/live-preview-react: 3.24.0
  @payloadcms/next/utilities: 3.24.0
  @payloadcms/payload-cloud: 3.24.0
  @payloadcms/plugin-form-builder: 3.24.0
  @payloadcms/plugin-nested-docs: 3.24.0
  @payloadcms/plugin-redirects: 3.24.0
  @payloadcms/plugin-search: 3.24.0
  @payloadcms/plugin-seo: 3.24.0
  @payloadcms/richtext-lexical: 3.24.0
  @payloadcms/translations: 3.24.0
  @payloadcms/ui/shared: 3.24.0
  react: 19.0.0
  react-dom: 19.0.0

[github-actions]

Please add a reproduction in order for us to be able to investigate.

Depending on the quality of reproduction steps, this issue may be closed if no reproduction is provided.

Why was this issue marked with the invalid-reproduction label?

To be able to investigate, we need access to a reproduction to identify what triggered the issue. We prefer a link to a public GitHub repository created with create-payload-app@beta -t blank or a forked/branched version of this repository with tests added (more info in the reproduction-guide).

To make sure the issue is resolved as quickly as possible, please make sure that the reproduction is as minimal as possible. This means that you should remove unnecessary code, files, and dependencies that do not contribute to the issue. Ensure your reproduction does not depend on secrets, 3rd party registries, private dependencies, or any other data that cannot be made public. Avoid a reproduction including a whole monorepo (unless relevant to the issue). The easier it is to reproduce the issue, the quicker we can help.

Please test your reproduction against the latest version of Payload to make sure your issue has not already been fixed.

I added a link, why was it still marked?

Ensure the link is pointing to a codebase that is accessible (e.g. not a private repository). "example.com", "n/a", "will add later", etc. are not acceptable links -- we need to see a public codebase. See the above section for accepted links.

Useful Resources

• Reproduction Guide
• Contributing to Payload

[oysteinwangen]

Here is a repo with a recreation of this problem: https://github.com/oysteinwangen/payload-unique-bug

To recreate this issue with non-unique slugs:

1. Start with the github repo above. It contains a Posts collection, with a title and a slug field. The unique is commented out for the slug field initially.
2. Use a fresh mongodb database.
3. Create one post.
4. Now go into the Posts collection and remove the comment on unique, so that unique is set to true for the slug field.
5. Try and create more posts with the same slug.
   Now you should see that you can create and save multiple posts with identical slugs, without any warning or error.

(If you create your first post with unique set to true from the beginning, then this isn't an issue).

Another issue about the same thing: Validation for scheduled publishing.

The unique validation isn't checked before pressing save or publish. This can cause problems when scheduling the publishing, as the user won't get a warning about invalid fields when clicking schedule...

[PatrikKozak]

Hey @oysteinwangen - thanks for bringing this up!

Something to note about indexes in MongoDB is that once an index is created on a field, it won’t automatically change if the field’s configuration is updated. So if you add unique: true after documents have already been created, the database will still use the original index, which isn’t unique.

To fix this, you can drop the existing index for that field and restart Payload—this will recreate the index as unique.

If you’re working with a large database and need to avoid dropping indexes in production, you can use a migration to apply the index instead using the mongoose model call syncIndexes() with payload.collections[myCollectionSlug].Model.syncIndexes().

For additional context: the unique constraint is enforced at the database level. When a field is updated to include unique: true, the database adapter won’t remove or alter existing indexes. Using a tool like MongoDB Compass to manually delete the index or dropping the collection (if data loss isn’t a concern) can also resolve the issue.

Regarding your note about validation for scheduled publishing—thanks for pointing that out as well!

Since that’s a separate issue, please open a new issue for it so we can track it properly. I’ll be closing this thread since the indexing behavior is expected due to the reasons mentioned above.

Thanks again for taking the time to report this!