Remove GraphQL GlobalIDType compatibility layer

Ha, no worries. I've gone ahead and set a Due Date of April 17th, so that we get a reminder to that it's coming due to be scheduled/assigned for %15.0

removed typefeature label

mentioned in merge request !77372 (merged)

mentioned in merge request !36209 (merged)

changed milestone to %15.0

@arturoherrero - fyi. We should schedule this for %15.0

If we can schedule it earlier, that would be nice as well, at this imposes a development burden.

@alexkalderimis Thanks for letting me know. cc. @g.hickman

I have a few questions:

In the description, we can read all stakeholders informed. Has this already happened, or do we need to do something else? Maybe we have to add an entry in https://docs.gitlab.com/ee/update/deprecations.html.
Do we need to work on this issue exactly at 15.0, or can we do it early, eg. 14.10?
Can you weigh the issue, please?

Has this already happened, or do we need to do something else? Maybe we have to add an entry in https://docs.gitlab.com/ee/update/deprecations.html.

It is not present in that list. I will get it added.

Do we need to work on this issue exactly at 15.0, or can we do it early, eg. 14.10?

We can probably do it earlier. I'm not entirely sure whose sign-off we would need

Can you weigh the issue, please?

Certainly - this is fairly mechanical really (lots of TODO comments, a few tests that will need to be deleted). I would weight it as backend-weight2

@alexkalderimis @arturoherrero Will this be a breaking change or what is the customer impact? If it's not a breaking change, we should be able to release sooner and just be sure to announce it 2 milestones prior to the removal.

It is not expected to be a breaking change, except in some very rare cases.

If a client somewhere out there is sending queries such as:

query($id: ID!) {
  issue(id: $id) {
    title
    description
  }
}

with variables:

{ "id": "gid://gitlab/Issue/102188595" }

which we accept right now, it will stop working. Instead they should send:

query($id: IssueID!) {
  issue(id: $id) {
    title
    description
  }
}

(the variables will not have to change).

That is the extent of the breakage - types named in query signatures might need updating. Values included inline will not need to be changed, which means this query:

query {
  issue(id: "gid://gitlab/Issue/102188595") {
    title
    description
  }
}

will work just fine.

The reason I say that breakage is unlikely is that users would have literally no reason to use ID. If you look at the docs for these features, they all list the correct argument types, eg.

gql> :type Query.issue
Issue
Find an issue.
arguments:
┌───────┬─────────────┬─────────────────────────────────────┬──────────────────┐
│name   │type         │description                          │deprecated?       │
├───────┼─────────────┼─────────────────────────────────────┼──────────────────┤
│id     │IssueID!     │Global ID of the issue.              │No                │
└───────┴─────────────┴─────────────────────────────────────┴──────────────────┘

and they have done for about over a year. Any user building a query will use the correct types. All our own queries have been updated.

If we are very worried, we can delay doing this until we put in some monitoring to determine how frequently users are passing in the wrong type to get a sense of the scale of any disruption. I would estimate the effort of introducing this monitoring as about backend-weight2 (we have very obvious places to put these logs).

Thoughts @g.hickman, @arturoherrero

That's super helpful @alexkalderimis. My vote is that we can remove early and we can communicate the minor risk ahead of time unless @arturoherrero objects.

@g.hickman @alexkalderimis Sounds good. I'm updating the description with the following plan:

Add the deprecation entry during %14.8 https://docs.gitlab.com/ee/update/deprecations.html
Proceed with the changes in %14.10 or %15.0. We can start as a Stretch issue for %14.10.

changed due date to April 17, 2022

added [deprecated] Accepting merge requests label

added Category:API backend groupintegrations [DEPRECATED] labels

set weight to 2

Setting label(s) devopsecosystem sectiondev based on ~"group::integrations".

added sectiondev + 1 deleted label

changed milestone to %14.8

added Stretch label

assigned to @alexkalderimis

changed the description

removed [deprecated] Accepting merge requests label

mentioned in merge request !80636 (merged)

marked the checklist item Update the deprecation list including this changes https://docs.gitlab.com/ee/update/deprecations.html as completed

added workflowin dev label

mentioned in issue #352832 (closed)

changed the description

marked this issue as related to #352832 (closed)

changed milestone to %14.10

marked the checklist item Update the milestone to %14.10 as completed

mentioned in merge request !83457 (merged)

marked the checklist item Remove the compatibility layer introduced in !36209 (merged), which overrides as completed

marked the checklist item Remove all the explicit coercions, marked where possible with TODOs as completed

mentioned in merge request !83640 (merged)

The removal MR has been split into two: !83640 (merged) and !83457 (merged)

The former blocks the latter, since we have to update some front-end queries that still have the old types in them (and we need to sequence these changes for safety).

We also have to determine if a compatibility feature for iteration cadences can be removed - if not then this will require a schema change and require moving !83457 (merged) to %15.0.

added workflowin review label and removed workflowin dev label

mentioned in merge request !84052 (merged)

marked this issue as related to #357461 (closed)

mentioned in issue #357461 (closed)

Remove GraphQL GlobalIDType compatibility layer

During %14.8

During %14.10 or %15.0

Designs

Child items ...

Activity

Remove GraphQL GlobalIDType compatibility layer

During %14.8

During %14.10 or %15.0

Blocks

Is blocked by

Activity