fix(core): prevent cached show page data in create forms

[Woutuuur]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://refine.dev/docs/guides-concepts/contributing/#commit-convention

Bugs / Features

• Related issue(s) linked
• Tests for the changes have been added
• Docs have been added / updated
• Changesets have been added https://refine.dev/docs/guides-concepts/contributing/#creating-a-changeset

What is the current behavior?

When opening a create modal (useModalForm with action: "create") on a show page for the same resource, the form's defaultValues are overwritten by cached data from the show page's useOne query. This happens because useForm passes the URL-derived id to useOne even for create actions, causing a query key collision with the cached entry. The useModalForm visibility reset effect then calls reset() with the cached show-page data, replacing the user-provided defaultValues.

What is the new behavior?

• core (useForm): id is no longer passed to useOne when the action is "create", preventing the cache key collision at the source.
• react-hook-form (useModalForm): The visibility reset effect is guarded against "create" actions, so it never calls reset() with query data for create forms.

Create modal forms now correctly retain their defaultValues regardless of cached data from the same resource.

[changeset-bot]

🦋 Changeset detected

Latest commit: fc27249

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[abhishekchauhan1365]

This looks like a solid fix and the root cause is clearly addressed.

Avoiding passing the id to useOne for "create" actions makes sense and eliminates the cache key collision at the source. The additional safeguard in useModalForm to skip reset() for create flows is a good defensive layer as well.

The regression test is especially valuable here since this kind of issue can easily resurface with future changes.

One small thing to clarify:

• Are there any edge cases where id might still be implicitly inferred (e.g., via URL params in custom setups) that could reintroduce similar collisions?

Otherwise, the approach is clean and well-scoped. Good to go from my side.