Skip to content

httpx CI group also runs httpx2 test suite #7151

Closed

Description

@sentrivana

Looks like the httpx target in the Networks group in CI is also testing httpx2.

Open httpx here, for instance: https://github.com/getsentry/sentry-python/actions/runs/31385230658/job/93444058506 It only contains httpx2 runs. Both httpx and httpx2 are run in the httpx group (I assume because we do/tox does some prefix matching). In Python 3.14, specifically, there are no httpx versions to run the tests against, so we only run them against httpx2.

This is not a big deal, but we could check whether we can isolate the test suites.

Activity

  1. linear-code commented on Aug 10, 2026

    @linear-code
  2. changed the title [-]httpx CI group runs httpx2 test suite[/-] [+]httpx CI group also runs httpx2 test suite[/+] on Aug 10, 2026
  3. ZaafirRizwan commented on Aug 15, 2026

    @ZaafirRizwan
    Contributor

    Hi! I'd like to work on this.

    I traced the collision to scripts/runtox.sh: the generated Network workflow invokes py<version>-httpx and py<version>-httpx2 separately, but runtox.sh uses an unanchored substring match over tox -l. As a result, py3.14-httpx selects the existing py3.14-httpx2-* environments even though there are no Python 3.14 httpx environments.

    I found the same prefix-collision precedent in #4730, where openai was renamed to openai_base rather than changing the intentionally broad selector.

    Would you prefer the same approach here—rename the tox suite factor to something like httpx1 or httpx_base, retain integration_name: "httpx", update the Network group, and regenerate tox.ini and the workflows—or would you rather make runtox.sh boundary-aware?

    I'll wait for confirmation on the preferred approach before implementing it.

  4. moved this to Waiting for: Product Owner in GitHub Issues with 👀 3on Aug 15, 2026
  5. sentrivana commented on Aug 17, 2026

    @sentrivana
    CollaboratorAuthor

    Hey @ZaafirRizwan. Generally, if there's a precedent I'd prefer we follow that, so in this case we could go with renaming the httpx group to something else, maybe httpx0 since it's still in 0.x?

    It'll need the additional integration_name, and maybe more -- check what we did in the analogous openai case.

    Feel free to go ahead and give this a shot.

  6. moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3on Aug 17, 2026
  7. Epsilon006 commented on Sep 5, 2026

    @Epsilon006

    Hi @ZaafirRizwan — are you still working on this? I don’t see an open PR linked yet. If you’ve stepped away, I’d be happy to take it.

    I’ll follow @sentrivana’s suggested precedent: rename the legacy httpx tox group (likely to httpx0), add integration_name, and mirror the analogous openai-base setup. I’ll reproduce the generated CI matrix locally first and keep the change focused.

  8. moved this to Waiting for: Product Owner in GitHub Issues with 👀 3on Sep 5, 2026
  9. ZaafirRizwan commented on Sep 5, 2026

    @ZaafirRizwan
    Contributor

    Hey @Epsilon006, thanks for checking in! Still on it. PR #7398 is up, taking exactly that approach (httpx0 + integration_name, mirroring openai-base).

  10. added a commit that references this issue on Sep 7, 2026
    fb85760
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions