Visitar URL original
gl.runner.all() causes tags to be repeated · Issue #2250 · python-gitlab/python-gitlab · GitHub
Skip to content

gl.runner.all() causes tags to be repeated #2250

Description

@max-wittig

Description of the problem, including code/CLI snippet

DEBUG:urllib3.connectionpool:[https://example.gitlab.com:443](https://example.gitlab.com/) "GET /api/v4/runners/all?type=project_type&tag_list=DOCKER HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:[https://example.gitlab.com:443](https://example.gitlab.com/) "GET /api/v4/runners/all?page=2&per_page=20&tag_list%5B%5D=DOCKER&type=project_type&tag_list=DOCKER HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:[https://example.gitlab.com:443](https://example.gitlab.com/) "GET /api/v4/runners/all?page=3&per_page=20&tag_list%5B%5D=DOCKER&type=project_type&tag_list=DOCKER HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:[https://example.gitlab.com:443](https://example.gitlab.com/) "GET /api/v4/runners/all?page=4&per_page=20&tag_list%5B%5D=DOCKER&type=project_type&tag_list=DOCKER HTTP/1.1" 200 None

Expected Behavior

tag_list is only attached once

Actual Behavior

tag_list is attached multiple times

Specifications

  • python-gitlab version: latest
  • API version you are using (v3/v4): v4
  • Gitlab server version (or gitlab.com): 15.2.1

Activity

  1. nejch commented on Aug 23, 2022

    @nejch
    Member

    Seems like we've been doing this for a long time, I can reproduce it with 3.0.0 at least, but probably goes way back.

    GitLab converts attribute names of arrays when returning the links headers (tag_list=bla -> tag_list[]=bla), and because the queries differ (attribute vs. attribute[]), requests does not de-duplicate them. We had the same issue with URL-encoding which we fixed here #2219.

    For list() calls we should be safe as they track the array attributes and know when to convert them even before sending. Probably 2 options/things to do:

    • add some handling to http_request() to also de-duplicate param vs param[]
    • try to always use ListMixin for any paginated response, and track array attributes (daydream: get it from openapi spec)

    I think it's not just runners.all() but any custom method that follows pagination links and is not aware of arrays. At least they are duplicated only once, not appended continuously though

  2. github-actions commented on Jul 9, 2025

    @github-actions

    This issue was marked stale because it has been open 60 days with
    no activity. Please remove the stale label or comment on this
    issue. Otherwise, it will be closed in 15 days.

    As an open-source project, we rely on community contributions to
    address many of the reported issues. Without a proposed fix or
    active work towards a solution it is our policy to close inactive
    issues. This is documented in CONTRIBUTING.rst

    How to keep this issue open:

    • If you are still experiencing this issue and are willing to
      investigate a fix, please comment and let us know.
    • If you (or someone else) can propose a pull request with a
      solution, that would be fantastic.
    • Any significant update or active discussion indicating progress
      will also prevent closure.

    We value your input. If you can help provide a fix, we'd be happy
    to keep this issue open and support your efforts.

    This is documented in CONTRIBUTING.rst
    https://github.com/python-gitlab/python-gitlab/blob/main/CONTRIBUTING.rst

  3. github-actions commented on Jul 24, 2025

    @github-actions

    This issue was closed because it has been marked stale for 15 days
    with no activity.

    This open-source project relies on community contributions, and
    while we value all feedback, we have a limited capacity to address
    every issue without a clear path forward.

    Currently, this issue hasn't received a proposed fix, and there
    hasn't been recent active discussion indicating someone is planning
    to work on it. To maintain a manageable backlog and focus our
    efforts, we will be closing this issue for now.

    This doesn't mean the issue isn't valid or important. If you or
    anyone else in the community is willing to investigate and propose
    a solution (e.g., by submitting a pull request), please do.

    We believe that those who feel a bug is important enough to fix
    should ideally be part of the solution. Your contributions are
    highly welcome.

    Thank you for your understanding and potential future
    contributions.

    This is documented in CONTRIBUTING.rst
    https://github.com/python-gitlab/python-gitlab/blob/main/CONTRIBUTING.rst

  4. locked as resolved and limited conversation to collaborators on Jul 27, 2026
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