It's totally main, since it can even be considered as a breaking change.

Why not using an allow list like suggested in the issue?

Thanks @alanpoulain for your quick feedback.

Maybe it was a mistake from my side to promote this issue as a workaround for #2736.
The main issue is #5097, which I created just now to explain the in my opinion wrong behaviour when using DTOs. So when I use DTOs for input I expect that this DTO will be exactly used as an input for the GraphQL Mutation and no id should be automatically added. If the mutation needs one it can be specified as a property within the DTO. So this PR is mainly fixing issue #5097.

But as mentioned it can additionally be considered as a workaround for #2736. But you are right, it does not mainly fix this issue and the propsal using an allow list will be still open. Sorry for misunderstanding.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Thank you @jotwea.

After some thought, maybe I will revert this PR. The condition is not right: we don't want to remove the ID for update and delete mutations.
You seem to use a custom mutation in your issue, but you don't use a custom resolver. I don't see how it can work.
Making the ID optional for custom mutations is probably a better way to solve your issue.

WDYT of this PR to replace yours?

#5359

I guess #5359 also solves the original problem mentioned in #5097 very well.

Your approach differs from mine that it is based on the existence of a resolver, mine is based on the existence of an input DTO. And you are right, I use a custom resolver as well in my project, so your solutions will work for me as well. The important thing is just that there will be a way to avoid an automatic id field.

Thanks for the answer.
It will be available in version 3.2.