Visitar URL original
Trying to Fetch multiple ProjectIssues in a single batch call returns only the last ProjectIssue specified in the list · Issue #1407 · python-gitlab/python-gitlab · GitHub
Skip to content

Trying to Fetch multiple ProjectIssues in a single batch call returns only the last ProjectIssue specified in the list #1407

Description

@aaronalphonso

Description of the problem, including code/CLI snippet

According to Gitlab, we can make a batch GET call to fetch multiple issues by passing in the list of issue_ids in parameter iids.

However, while using the library this method call always returns a list with a single element (which happens to be the last element in the iids list.

project = gl.projects.get(project_id)
project.issues.list(all=True, iids=[1, 2, 3])   # Returns a list with a single element ProjectIssue[iid=3]
project.issues.list(all=True, iids=[3, 2, 1])   # Returns a list with a single element ProjectIssue[iid=1]

Are batch requests not supported yet or is this a bug?

Expected Behavior

The batch call should return a list of all ProjectIssues as mentioned in the iids field.

project = gl.projects.get(project_id)
project.issues.list(all=True, iids=[1, 2, 3])   # Should return [ProjectIssue(iid=1), ProjectIssue(iid=2), ProjectIssue(iid=3)]

Actual Behavior

Only the ProjectIssue corresponding to the last id in the iids list is returned

project = gl.projects.get(project_id)
project.issues.list(all=True, iids=[1, 2, 3])    # Returns a list with a single element ProjectIssue[iid=3]

Specifications

  • python-gitlab version: 2.6.0
  • API version you are using (v3/v4): v4
  • Gitlab server version (or gitlab.com): GitLab Community Edition 13.10.2

Activity

  1. changed the title [-]Trying to Fetch multiple ProjectIssues by a single batch call returns only the last ProjectIssue specified in the list[/-] [+]Trying to Fetch multiple ProjectIssues in a single batch call returns only the last ProjectIssue specified in the list[/+] on Apr 23, 2021
  2. nejch commented on Apr 23, 2021

    @nejch
    Member

    This seems related to some other issues where lists aren't passed to query params correctly, I'll check. I think we have a similar issue with scopes.

    Out of curiosity, have you tried passing the iids as a comma-delimited string? Would need to check what the current state of the gitlab API is with this (see e.g. https://gitlab.com/gitlab-org/gitlab-foss/-/issues/48007)

  3. aaronalphonso commented on Apr 23, 2021

    @aaronalphonso
    Author

    I just tried passing in iids as a comma-delimted string and it gives me the expected results. Thank you very much for the suggestion! :)

  4. JohnVillalovos commented on Apr 25, 2021

    @JohnVillalovos
    Member

    EDIT: Now I am less sure. I need to do more investigation... I'm pretty sure that the patch as it is right now will not work 😢

    I have proposed a patch for this issue in #1413

    I'm hopeful that it will work though I have not tested it.

  5. JohnVillalovos commented on Apr 25, 2021

    @JohnVillalovos
    Member

    EDIT: So after further research believe the problem is python-gitlab. Created issue for it: #1419

    I have left a comment on the MR, which seems to have caused this behavior in Gitlab:

    https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33450

  6. JohnVillalovos commented on Apr 26, 2021

    @JohnVillalovos
    Member

    Related issue: #1256

  7. JohnVillalovos commented on Apr 27, 2021

    @JohnVillalovos
    Member

    @nejch I think I may have found out our root cause issue.

    Had a discussion with a Gitlab developer in: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33450

    From the Gitlab documentation: https://docs.gitlab.com/ee/api/#array

    array

    import_sources is a parameter of type array:

    curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
    -d "import_sources[]=github" \
    -d "import_sources[]=bitbucket" \
    "https://gitlab.example.com/api/v4/some_endpoint"
    

    So it seems for array types we need to append [] to the variable name.

  8. locked as resolved and limited conversation to collaborators on May 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions