Create mechanism to remove graphql mutations automatically at a future date

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Problem

Because graphql is self-documenting, the moment a graphql mutation is added to GitLab it becomes a supported feature. In order to remove it, it should go through the lengthy process of deprecation and removal.

The problem with this is that an engineer may introduce a mutation that is for an MVC or internal usage only. After a release or two, they may no longer need the mutation, and that mutation is now a maintenance liability. At that point, an engineer should announce a deprecation and removal via our standard process.

The problem is the engineer needs to return to the code just prior to a MAJOR release to actually remove the mutation. This is often done by adding "Todo: remove in XX.0" into the code, such as this example.

  • This "todo" is hard to track since it can be in the distant future.
  • An issue has to be opened up and given a very specific milestone
  • The engineer working on the code may change
  • If the code isn't removed at just the right time, the mutation carries into a version where it shouldn't exist, hurting the accuracy and credibility of our deprecation/removal process.

We need an efficient way for engineers to deprecate and remove mutations without having to come back to code at a specific time in the future.

Proposal

Introduce a helper function like 'remove_on' that permits an engineer to remove a mutation at a specific release without having to create a new MR in the future.

The functionality to automatically remove a mutation on version 16 could look something like:

 class MutationWeWantToRemove < BaseMutation
      graphql_name 'MutationWeWantToRemove'
      remove_on '16'

The above code would ensure that if the GitLab version is 16+ that mutation would no longer respond.

Benefits

This would allow an engineer to deprecate and "remove" from graphql a mutation in a single MR, and eliminates the need to schedule follow issues/MRs.

This would also encourage engineers to keep their code tidy and deprecate and remove more things, easing our maintenance burden. The current process is cumbersome and therefore discourages us from deprecating/removing unused mutations.

This will lead to dead code, however that dead code can easily be cleaned up in a single MR without subject matter expertise since we know the code is not used. This is in constrast to removing code that has a comment that says #TODO: remove in 16.0, which can't automatically be removed.

Edited by 🤖 GitLab Bot 🤖