Skip to content

Resolve "Allow issue's Internal ID (`iid`) to be set when creating via the API"

Jamie Schembri requested to merge shkm/gitlab-ce:1756-set-iid-via-api into master

What does this MR do?

When a resource with an atomic ID has an iid set, it will be now be created with that iid, and the last_value will be updated on the internal_id.

This does mean that internal IDs may no longer be a "strictly monotone sequence of integers", so keep that in mind.

Please see the issue, #1756 (closed), for the use case.

Added some tests, and tested manually locally with the following:

curl --request POST \
  --url http://localhost:3000/api/v4/projects/1/issues \
  --header 'content-type: application/json' \
  --header 'private-token: FILLMEIN' \
  --data '{
	"title": "Foobar",
	"iid": 9001
}'

On master, iid does not reflect what is posted. On this branch, it does.

P.S. Huge thanks to @abrandl for taking plenty of time to explain this issue.

Are there points in the code the reviewer needs to double check?

Is it OK that we may now have gaps in issues' iid column?

Decision: Yes.

How should we handle a case in which the new issue's IID is less than the current last value? With these commits, I may create an issue 9000 after 9001. Maybe that's OK?

Decision: Yes, that's ok but not always possible (if we hit the unique key constraint, we will fail the API call)

Do we prefer the API param iid or issue_iid? iid is usually the return value, and issue_iid is just used when it's part of the path. I went with iid.

Decision: iid is fine

Why was this MR needed?

There's an issue :-).

Screenshots (if relevant)

Does this MR meet the acceptance criteria?

What are the relevant issue numbers?

Closes #1756 (closed)

Edited by Andreas Brandl

Merge request reports