fix: exclude kubernetes client 36.0.0 to avoid anonymous auth bug by krcmarik · Pull Request #516 · RedHatQE/mtv-api-tests

krcmarik · 2026-05-25T19:13:31Z

Kubernetes Python client 36.0.0 has a confirmed regression where Configuration.auth_settings() looks for api_key['BearerToken'] but all config loaders still write api_key['authorization']. This causes every authenticated request to silently fall back to system:anonymous.

Error example:
kubernetes.dynamic.exceptions.ForbiddenException:
(403) Reason: Forbidden
"system:anonymous" cannot get path "/apis"

Upstream issues:
kubernetes-client/python#2582

Fix merged upstream (PR #2585) but no new release yet. Exclude kubernetes client 36.0.0 until a patched release is available.

Summary by CodeRabbit

Chores
- Updated Kubernetes dependency version constraint to support versions below 36.

qodo-code-review · 2026-05-25T19:13:46Z

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (2)

1. Missing kubernetes minimum version 🐞 Bug ☼ Reliability ⭐ New

Description

The new dependency constraint only excludes kubernetes==36.0.0 and provides no lower bound, so
non-locked installs (or installs influenced by other constraints) can resolve to older kubernetes
versions and fail imports like kubernetes.dynamic.DynamicClient used throughout the suite.

Evidence

The dependency constraint added in pyproject lacks a lower bound, while multiple modules import
kubernetes.dynamic APIs at runtime; uv.lock shows the project is currently resolved/tested with
kubernetes 35.0.0, suggesting a practical minimum to encode in pyproject.

pyproject.toml[35-68]
utilities/utils.py[15-18]
conftest.py[16-22]
uv.lock[1004-1022]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pyproject.toml` adds `kubernetes!=36.0.0` without a minimum version. The codebase imports `kubernetes.dynamic` APIs, so allowing arbitrarily old kubernetes versions (in non-locked installs or when other constraints affect resolution) risks runtime import errors and reduces reproducibility.

## Issue Context
- The repo installs dependencies via `uv sync --locked` in container builds, but `pyproject.toml` is still the published/runtime dependency contract.
- `uv.lock` currently resolves kubernetes to 35.0.0, which is a good candidate for a minimum bound if that’s the baseline you test/support.

## Fix Focus Areas
- pyproject.toml[35-68]
- uv.lock[1004-1022]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. README missing kubernetes pin note 📘 Rule violation ⚙ Maintainability

Description

The PR changes runtime dependency requirements by adding kubernetes!=36.0.0, but README
installation/troubleshooting guidance is not updated to reflect this new constraint and its
rationale. This can confuse users who troubleshoot auth/403 issues or try to reproduce dependency
resolution locally.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A new dependency constraint `kubernetes!=36.0.0` was introduced, but README.md does not mention this requirement change or why it exists.

## Issue Context
README.md already documents at least one dependency pin/workaround (`urllib3<2.4.0`) in the local-run prerequisites section; the kubernetes-client regression/pin should be similarly discoverable for users.

## Fix Focus Areas
- pyproject.toml[64-68]
- README.md[936-985]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. Pin intent unclear 🐞 Bug ⚙ Maintainability

Description

pyproject.toml excludes only kubernetes==36.0.0 (via kubernetes!=36.0.0), which is materially
different from a general “pin kubernetes <36” and can confuse future updates/triage. Because there’s
no inline rationale next to the constraint, it’s easy for someone to “fix” it later (e.g.,
loosen/remove it) without realizing it was added to avoid a specific regression.

Evidence

The dependency constraint added is a single-version exclusion (!=36.0.0) with no adjacent comment
explaining its purpose, so the intent is not captured in the code where future maintainers will
look.

pyproject.toml[35-68]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pyproject.toml` adds `kubernetes!=36.0.0` without documenting *why* this specific exclusion exists and how it differs from a broader `<36` pin. This makes future dependency bumps risky because maintainers may misread the constraint and change/remove it incorrectly.

## Issue Context
The dependency list is the primary source of truth for consumers and for future maintainers reviewing dependency policy.

## Fix Focus Areas
- pyproject.toml[35-68]

## Suggested fix
- Add a short TOML comment immediately above the `kubernetes!=36.0.0` entry explaining:
 - the regression being avoided,
 - the upstream issue/PR reference,
 - and what condition should trigger removing/updating the constraint (e.g., once a fixed release is available).
- Ensure the PR title/description reflects the actual constraint semantics (single-version exclusion vs broad `<36` pin).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

View more (2)

4. Direct kubernetes dependency added 📘 Rule violation ⚙ Maintainability

Description

The PR adds a direct runtime dependency on the kubernetes Python client, which conflicts with the
requirement to standardize cluster interactions on openshift-python-wrapper and avoid direct
kubernetes usage. Keeping kubernetes as a first-class dependency increases the risk of
non-compliant direct imports/usage creeping into runtime code.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A direct dependency on the `kubernetes` client was added (`kubernetes<36`). Compliance requires avoiding direct kubernetes usage in runtime and standardizing on `openshift-python-wrapper`.

## Issue Context
The change is intended to work around an upstream kubernetes-client regression by pinning the kubernetes package. However, adding `kubernetes` as a direct dependency can violate the policy even if code does not directly import it.

## Fix Focus Areas
- pyproject.toml[67-67]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

5. Overbroad kubernetes pin 🐞 Bug ⚙ Maintainability

Description

The dependency constraint kubernetes<36 blocks *all* 36.x versions, so even after upstream
releases a fixed 36.0.1+ the project will remain stuck on 35.x until someone manually updates the
pin. This increases long-term maintenance burden and can delay important bug/security fixes that
land in 36.x patch releases.

Evidence

The added dependency line explicitly enforces <36, which by definition disallows all 36.x versions
(including future patched releases). The lock metadata mirrors this constraint and currently locks
kubernetes to 35.0.0, confirming the broad pin is applied in the reproducible environment too.

pyproject.toml[63-68]
uv.lock[1196-1205]
uv.lock[1004-1022]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pyproject.toml` currently pins `kubernetes<36`, which prevents adopting any 36.x release (including the eventual fixed patch release). The PR intent is to avoid the known-bad `36.0.0` regression, so the constraint should exclude only that version.

## Issue Context
- The repo uses `uv sync --locked` for reproducible installs (see Dockerfile), so `uv.lock` should be updated to match any dependency spec change.

## Fix
- Replace `kubernetes<36` with a more precise constraint like `kubernetes!=36.0.0` (optionally also add a tested lower bound, e.g. `>=35.0.0`).
- Regenerate/update `uv.lock` so the locked environment reflects the new constraint.
- (Optional) Add a short comment in `pyproject.toml` referencing the upstream regression/issue for future cleanup.

## Fix Focus Areas
- pyproject.toml[63-68]
- uv.lock[1196-1205]
- uv.lock[1004-1022]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Previous review results

Review updated until commit 4fca363

Results up to commit a79a1c6

🐞 Bugs (1) 📘 Rule violations (1) 📎 Requirement gaps (0)

1. Direct kubernetes dependency added 📘 Rule violation ⚙ Maintainability

Description

The PR adds a direct runtime dependency on the kubernetes Python client, which conflicts with the
requirement to standardize cluster interactions on openshift-python-wrapper and avoid direct
kubernetes usage. Keeping kubernetes as a first-class dependency increases the risk of
non-compliant direct imports/usage creeping into runtime code.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A direct dependency on the `kubernetes` client was added (`kubernetes<36`). Compliance requires avoiding direct kubernetes usage in runtime and standardizing on `openshift-python-wrapper`.

## Issue Context
The change is intended to work around an upstream kubernetes-client regression by pinning the kubernetes package. However, adding `kubernetes` as a direct dependency can violate the policy even if code does not directly import it.

## Fix Focus Areas
- pyproject.toml[67-67]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Overbroad kubernetes pin 🐞 Bug ⚙ Maintainability

Description

The dependency constraint kubernetes<36 blocks *all* 36.x versions, so even after upstream
releases a fixed 36.0.1+ the project will remain stuck on 35.x until someone manually updates the
pin. This increases long-term maintenance burden and can delay important bug/security fixes that
land in 36.x patch releases.

Evidence

The added dependency line explicitly enforces <36, which by definition disallows all 36.x versions
(including future patched releases). The lock metadata mirrors this constraint and currently locks
kubernetes to 35.0.0, confirming the broad pin is applied in the reproducible environment too.

pyproject.toml[63-68]
uv.lock[1196-1205]
uv.lock[1004-1022]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pyproject.toml` currently pins `kubernetes<36`, which prevents adopting any 36.x release (including the eventual fixed patch release). The PR intent is to avoid the known-bad `36.0.0` regression, so the constraint should exclude only that version.

## Issue Context
- The repo uses `uv sync --locked` for reproducible installs (see Dockerfile), so `uv.lock` should be updated to match any dependency spec change.

## Fix
- Replace `kubernetes<36` with a more precise constraint like `kubernetes!=36.0.0` (optionally also add a tested lower bound, e.g. `>=35.0.0`).
- Regenerate/update `uv.lock` so the locked environment reflects the new constraint.
- (Optional) Add a short comment in `pyproject.toml` referencing the upstream regression/issue for future cleanup.

## Fix Focus Areas
- pyproject.toml[63-68]
- uv.lock[1196-1205]
- uv.lock[1004-1022]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit 4fca363

🐞 Bugs (1) 📘 Rule violations (1) 📎 Requirement gaps (0)

1. README missing kubernetes pin note 📘 Rule violation ⚙ Maintainability

Description

The PR changes runtime dependency requirements by adding kubernetes!=36.0.0, but README
installation/troubleshooting guidance is not updated to reflect this new constraint and its
rationale. This can confuse users who troubleshoot auth/403 issues or try to reproduce dependency
resolution locally.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A new dependency constraint `kubernetes!=36.0.0` was introduced, but README.md does not mention this requirement change or why it exists.

## Issue Context
README.md already documents at least one dependency pin/workaround (`urllib3<2.4.0`) in the local-run prerequisites section; the kubernetes-client regression/pin should be similarly discoverable for users.

## Fix Focus Areas
- pyproject.toml[64-68]
- README.md[936-985]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Pin intent unclear 🐞 Bug ⚙ Maintainability

Description

pyproject.toml excludes only kubernetes==36.0.0 (via kubernetes!=36.0.0), which is materially
different from a general “pin kubernetes <36” and can confuse future updates/triage. Because there’s
no inline rationale next to the constraint, it’s easy for someone to “fix” it later (e.g.,
loosen/remove it) without realizing it was added to avoid a specific regression.

Evidence

The dependency constraint added is a single-version exclusion (!=36.0.0) with no adjacent comment
explaining its purpose, so the intent is not captured in the code where future maintainers will
look.

pyproject.toml[35-68]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pyproject.toml` adds `kubernetes!=36.0.0` without documenting *why* this specific exclusion exists and how it differs from a broader `<36` pin. This makes future dependency bumps risky because maintainers may misread the constraint and change/remove it incorrectly.

## Issue Context
The dependency list is the primary source of truth for consumers and for future maintainers reviewing dependency policy.

## Fix Focus Areas
- pyproject.toml[35-68]

## Suggested fix
- Add a short TOML comment immediately above the `kubernetes!=36.0.0` entry explaining:
 - the regression being avoided,
 - the upstream issue/PR reference,
 - and what condition should trigger removing/updating the constraint (e.g., once a fixed release is available).
- Ensure the PR title/description reflects the actual constraint semantics (single-version exclusion vs broad `<36` pin).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

rh-bot-1 · 2026-05-25T19:14:03Z

Report bugs in Issues

Welcome! 🎉

This pull request will be automatically processed with the following features:

🔄 Automatic Actions

Reviewer Assignment: Reviewers are automatically assigned based on the OWNERS file in the repository root
Size Labeling: PR size labels (XS, S, M, L, XL, XXL) are automatically applied based on changes
Issue Creation: Disabled for this repository
Branch Labeling: Branch-specific labels are applied to track the target branch
Auto-verification: Auto-verified users have their PRs automatically marked as verified
Labels: All label categories are enabled (default configuration)

📋 Available Commands

PR Status Management

/wip - Mark PR as work in progress (adds WIP: prefix to title)
/wip cancel - Remove work in progress status
/hold - Block PR merging (approvers only)
/hold cancel - Unblock PR merging
/verified - Mark PR as verified
/verified cancel - Remove verification status
/reprocess - Trigger complete PR workflow reprocessing (useful if webhook failed or configuration changed)
/regenerate-welcome - Regenerate this welcome message

Review & Approval

/lgtm - Approve changes (looks good to me)
/approve - Approve PR (approvers only)
/automerge - Enable automatic merging when all requirements are met (maintainers and approvers only)
/assign-reviewers - Assign reviewers based on OWNERS file
/assign-reviewer @username - Assign specific reviewer
/check-can-merge - Check if PR meets merge requirements

Testing & Validation

/retest tox - Run Python test suite with tox
/retest build-container - Rebuild and test container image
/retest conventional-title - Validate commit message format
/retest all - Run all available tests

Container Operations

/build-and-push-container - Build and push container image (tagged with PR number)
- Supports additional build arguments: /build-and-push-container --build-arg KEY=value

Cherry-pick Operations

/cherry-pick <branch> - Schedule cherry-pick to target branch when PR is merged
- Multiple branches: /cherry-pick branch1 branch2 branch3

Label Management

/<label-name> - Add a label to the PR
/<label-name> cancel - Remove a label from the PR

✅ Merge Requirements

This PR will be automatically approved when the following conditions are met:

Approval: /approve from at least one approver
Status Checks: All required status checks must pass
No Blockers: No wip, hold, has-conflicts labels and PR must be mergeable (no conflicts)
Verified: PR must be marked as verified

📊 Review Process

Approvers and Reviewers

Approvers:

myakove
solenoci

Reviewers:

krcmarik
myakove
solenoci

Available Labels

hold
verified
wip
lgtm
approve
automerge

AI Features

Conventional Title: Mode: fix (claude/claude-opus-4-6[1m])
Cherry-Pick Conflict Resolution: Enabled (claude/claude-opus-4-6[1m])
Test Oracle: Triggers: approved (cursor/gpt-5.4-xhigh-fast); /test-oracle can be used anytime

💡 Tips

WIP Status: Use /wip when your PR is not ready for review
Verification: The verified label is removed on new commits unless the push is detected as a clean rebase
Cherry-picking: Cherry-pick labels are processed when the PR is merged
Container Builds: Container images are automatically tagged with the PR number
Permission Levels: Some commands require approver permissions
Auto-verified Users: Certain users have automatic verification and merge privileges

For more information, please refer to the project documentation or contact the maintainers.

coderabbitai · 2026-05-25T19:14:26Z

Warning

Review limit reached

@krcmarik, we couldn't start this review because you've used your available PR reviews for now.

Your plan includes 1 review of capacity. Refill in 29 minutes and 43 seconds.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more review capacity refills, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than trial, open-source, and free plans. In all cases, review capacity refills continuously over time.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: c4559ca4-0ea5-46c3-bec5-eaf35ab0bc4c

📥 Commits

Reviewing files that changed from the base of the PR and between 320c849 and 4fca363.

⛔ Files ignored due to path filters (1)

uv.lock is excluded by !**/*.lock

📒 Files selected for processing (1)

pyproject.toml

Walkthrough

A single dependency constraint kubernetes<36 was added to the project's runtime dependencies in pyproject.toml. This change pins the Kubernetes client library to a major version below 36, preventing automatic adoption of incompatible future releases.

Changes

Dependency Update

Layer / File(s)	Summary
Kubernetes dependency version constraint `pyproject.toml`	`kubernetes<36` version constraint added to the `[project].dependencies` list, capping the Kubernetes client library at major version 35.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title directly and clearly describes the main change: excluding kubernetes client 36.0.0 to fix an authentication bug. It matches the changeset which adds a kubernetes<36 constraint to dependencies.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

qodo-code-review · 2026-05-25T19:16:49Z

Persistent review updated to latest commit a79a1c6

Kubernetes Python client 36.0.0 has a confirmed regression where Configuration.auth_settings() looks for api_key['BearerToken'] but all config loaders still write api_key['authorization']. This causes every authenticated request to silently fall back to system:anonymous. Error example: kubernetes.dynamic.exceptions.ForbiddenException: (403) Reason: Forbidden "system:anonymous" cannot get path "/apis" Upstream issues: kubernetes-client/python#2582 Fix merged upstream (PR #2585) but no 36.0.1 release yet. Using !=36.0.0 so future patched releases are picked up automatically.

qodo-code-review · 2026-05-25T19:25:59Z

Persistent review updated to latest commit 4fca363

qodo-code-review · 2026-05-25T19:28:41Z

Persistent review updated to latest commit 4fca363

krcmarik · 2026-05-25T19:39:20Z

/cherry-pick v2.11 v2.10

redhat-qe-bot · 2026-05-25T19:39:36Z

Cherry-pick requested for PR: fix: exclude kubernetes client 36.0.0 to avoid anonymous auth bug by user krcmarik
Adding label/s cherry-pick-v2.10 cherry-pick-v2.11 for automatic cherry-pick once the PR is merged

krcmarik · 2026-05-25T19:40:04Z

@coderabbitai review

coderabbitai · 2026-05-25T19:40:09Z

✅ Actions performed

Review triggered.

krcmarik · 2026-05-25T19:43:48Z

@coderabbitai full review

coderabbitai · 2026-05-25T19:43:53Z

✅ Actions performed

Full review triggered.

krcmarik · 2026-05-25T19:48:18Z

/verified

myakove · 2026-05-26T15:14:41Z

@krcmarik please see qodo comments #516 (comment)

myakove · 2026-05-26T15:42:58Z

@krcmarik fixed in the wrapper RedHatQE/openshift-python-wrapper#2730

Fix avaliable in https://github.com/RedHatQE/openshift-python-wrapper/releases/tag/v11.0.130

krcmarik · 2026-05-26T17:28:35Z

@myakove so I guess we do not need this here If the constraint is in openshift-python-wrapper, can we update the uv.lock to get it in?

myakove · 2026-05-26T17:30:22Z

Yes, please close this PR and open new one for update ocp wrapper version

rh-bot-1 requested a review from solenoci May 25, 2026 19:14

rh-bot-1 assigned krcmarik May 25, 2026

rh-bot-1 requested a review from myakove May 25, 2026 19:14

rh-bot-1 added branch-main size/XL labels May 25, 2026

coderabbitai Bot previously approved these changes May 25, 2026

View reviewed changes

redhat-qe-bot1 added the lgtm-coderabbitai[bot] label May 25, 2026

krcmarik dismissed coderabbitai[bot]’s stale review via 4fca363 May 25, 2026 19:25

krcmarik force-pushed the k8s_client_pin branch from a79a1c6 to 4fca363 Compare May 25, 2026 19:25

redhat-qe-bot1 removed the lgtm-coderabbitai[bot] label May 25, 2026

krcmarik changed the title ~~fix: pin kubernetes client <36 to avoid anonymous auth bug~~ fix: exclude kubernetes client 36.0.0 to avoid anonymous auth bug May 25, 2026

redhat-qe-bot added cherry-pick-v2.10 cherry-pick-v2.11 labels May 25, 2026

redhat-qe-bot1 added the verified label May 25, 2026

myakove mentioned this pull request May 26, 2026

fix: prefer kubeconfig over username/password authentication #517

Open

krcmarik closed this May 26, 2026

Conversation

krcmarik commented May 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary by CodeRabbit

Uh oh!

qodo-code-review Bot commented May 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Previous review results

Uh oh!

rh-bot-1 commented May 25, 2026

Welcome! 🎉

🔄 Automatic Actions

📋 Available Commands

PR Status Management

Review & Approval

Testing & Validation

Container Operations

Cherry-pick Operations

Label Management

✅ Merge Requirements

📊 Review Process

💡 Tips

Uh oh!

coderabbitai Bot commented May 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review limit reached

Walkthrough

Changes

Estimated code review effort

Uh oh!

qodo-code-review Bot commented May 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qodo-code-review Bot commented May 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qodo-code-review Bot commented May 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

krcmarik commented May 25, 2026

Uh oh!

redhat-qe-bot commented May 25, 2026

Uh oh!

krcmarik commented May 25, 2026

Uh oh!

coderabbitai Bot commented May 25, 2026

Uh oh!

krcmarik commented May 25, 2026

Uh oh!

coderabbitai Bot commented May 25, 2026

Uh oh!

krcmarik commented May 25, 2026

Uh oh!

myakove commented May 26, 2026

Uh oh!

myakove commented May 26, 2026

Uh oh!

krcmarik commented May 26, 2026

Uh oh!

myakove commented May 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

krcmarik commented May 25, 2026 •

edited

Loading

qodo-code-review Bot commented May 25, 2026 •

edited

Loading

coderabbitai Bot commented May 25, 2026 •

edited

Loading

qodo-code-review Bot commented May 25, 2026 •

edited

Loading

qodo-code-review Bot commented May 25, 2026 •

edited

Loading

qodo-code-review Bot commented May 25, 2026 •

edited

Loading