@jasonbahl this is proof of concept Once I get feedback/approval on this, I'll start work on the other mutations, then connections.

Coverage increased (+0.03%) to 79.299% when pulling 7985677 on justlevine:feat/comment-mutation-id-inputs into 2ee200f on wp-graphql:develop.

Code Climate has analyzed commit 5ca7196 and detected 0 issues on this pull request.

View more on Code Climate.

Sorry, accidentally pushed media items to this PR, just reverted.

Have you done a pretty thorough audit and have a list of all the fields that need to be addressed?

I was going to, but then I realized its just a simple search for => 'ID'.

I can take a beat and write them out if you want.

I wonder if it might make sense to create a feature branch for this, which is opened as a PR to develop, then we can make small iterative PRs to that feature branch, and work toward a larger merge with several of these PRs accumulated?

Your call. I personally try to avoid feature branches whenever for the same reason I'm submitting these PRs piecemeal - merge conflicts are a PITA.

If you're looking to prep for a near-term release and are worried about confusing users by enhancing the mutations/connection args incrementally, then feature branch is probably the way to go. But I can also make the argument that since the accepted ID inputs are confusing users in their current state, so even if they were added incrementally over a few releases, it'd still lessen the confusion. 🤷‍♂️

Without being too optimistic, updating mutation inputs is pretty straightforward. The only thing that might slow me down is backfilling missing tests.

Connections are going require a larger discussion over in #998 - the question of where in the lifecycle to make the change needs to be thought out foundationally (e.g. is the db or global id saved to $query_args['graphql_args']), and on an individual basis (even with AbstractConnectionResolver, each connection have their own order for calling parent methods / processing the args).