fix(platform): accept the container gpu-operator variant in iaas by lexfrei · Pull Request #4101 · cozystack/cozystack

Aleksei Sviridkin (lexfrei) · 2026-09-06T23:49:11Z

What this PR does

bundles.iaas.gpuOperatorVariant: container failed the whole platform render. The cozystack.gpu-operator PackageSource ships that variant, values-container.yaml configures it deliberately, and hack/check-gpu-operator-variants.bats covers it, but the iaas bundle guard only accepted default and vgpu.

The exclusion made sense when it was written and stopped making sense a few minutes later. The variant and the guard came from parallel branches, neither an ancestor of the other, variant merged first. Before the guard the bundle hardcoded default, so container was selected by hand-writing a Package CR, and leaving it out of a bundle-side list cost nothing. The guard made the bundle the variant owner and closed that route without noticing it was one. Its comment calls itself typo protection and names passthrough as the example typo.

Allowing the value is not the whole fix. The same file puts extraFeatureGates: [HostDevices] on the KubeVirt CR whenever gpu-operator is enabled, and builds a permittedHostDevices table under it. Both are VM-facing. The container variant keeps the host driver bound and pins vfioManager off, so no GPU reaches a VM: the gate would advertise something the node cannot serve, and the table would name resources no sandbox device plugin registers there. Both now render for default and vgpu only, and container gets the gpu-operator Package with the kubevirt component untouched.

The helm-unittest case that pinned the rejection is gone. Two replace it: the Package renders at the container variant with no component overrides, and the KubeVirt wiring stays absent even with gpu.permittedHostDevices and gpu.mediatedDevicesConfiguration set. Comments and docs that called the mirroring unconditional on variant, or the container variant unmerged, are fixed in the same pass.

No issue for this one, so the history is in the body.

Screenshots

No UI change.

Downstream repositories

Walked the trigger map against the diff. The only file it touches that appears there is packages/core/platform/values.yaml, and the website hit is not the hand-written key table (that page has no GPU section): it is the documented workaround this change makes obsolete. content/en/docs/next/operations/gpu-container-workloads.md currently tells readers the bundle rejects container and routes them to a hand-crafted Package CR, and virtualization/gpu.md / vgpu.md describe the KubeVirt mirroring as unconditional on variant.

Filed as an issue rather than a PR because the docs must not land ahead of this change, and the v1.6 copies describe released behaviour and stay correct as they are.

Nothing else matches: no package added, renamed or removed, no values.schema.json or version enum touched, no ApplicationDefinition semantics, no installer values key, no hack/ layout change, no platform variant or bundle recomposed. gpuOperatorVariant appears in none of ccp, ansible-cozystack or terraform-provider-cozystack.

Release note

fix(platform): accept `container` as a value for `bundles.iaas.gpuOperatorVariant`, so the gpu-operator variant the platform already ships can be selected from platform values instead of a hand-crafted Package CR. The KubeVirt `HostDevices` feature gate and `permittedHostDevices` table are now emitted for the `default` and `vgpu` variants only; `container` serves GPUs to pods and gets neither.

Summary by CodeRabbit

New Features
- Added the container GPU operator variant for workloads that do not require VM passthrough.
- Container workloads no longer receive KubeVirt host-device or mediated-device GPU wiring.
- Clarified GPU configuration behavior for passthrough, vGPU, SR-IOV, and container workloads.
Documentation
- Updated passthrough guidance, configuration references, examples, and KubeVirt wiring instructions for all supported variants.
- Added details for manually configured package resources and platform-specific container setup.

coderabbitai · 2026-09-06T23:49:30Z

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Team

Run ID: e0a0c141-78f9-467d-9235-940e723963c2

📥 Commits

Reviewing files that changed from the base of the PR and between cd675e1 and 1ca93cc.

📒 Files selected for processing (5)

docs/gpu-vgpu.md
packages/core/platform/templates/bundles/iaas.yaml
packages/core/platform/tests/bundles_gpu_kubevirt_wiring_test.yaml
packages/core/platform/values.yaml
packages/system/gpu-operator/examples/README.md

Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review.

📝 Walkthrough

Walkthrough

The GPU bundle now accepts the container variant. This variant emits the GPU operator without VM-facing KubeVirt GPU wiring. Tests and documentation cover validation, configuration, passthrough, vGPU, and manual Package CR behavior.

Changes

GPU container variant

Layer / File(s)	Summary
Bundle validation and variant rendering `packages/core/platform/templates/bundles/iaas.yaml`	The bundle accepts `default`, `vgpu`, and `container`. The `container` variant omits the HostDevices gate and VM GPU device wiring.
Container variant validation tests `packages/core/platform/tests/bundles_gpu_kubevirt_wiring_test.yaml`	Tests validate container Package emission, invalid variant errors, omitted KubeVirt GPU fields, and preservation of unrelated KubeVirt values.
Variant configuration guidance `docs/gpu-vgpu.md`, `packages/core/platform/values.yaml`, `packages/system/gpu-operator/examples/README.md`	Documentation describes container as a pod-only option, VM wiring for `default` and `vgpu`, conditional defaults, device support, and configuration examples.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Merge Risk: ⚪ Minimal · up to 6e856

This change enables the pod-only container GPU operator variant while preventing KubeVirt GPU wiring from being rendered for it. The intended behavior is covered by validation and rendering tests, with no active merge-blocking risk identified.

Sequence Diagram(s)

sequenceDiagram
  participant Operator
  participant PlatformBundle
  participant GpuOperator
  participant KubeVirt
  Operator->>PlatformBundle: Set gpuOperatorVariant: container
  PlatformBundle->>GpuOperator: Emit container Package
  PlatformBundle->>KubeVirt: Omit HostDevices and GPU device configuration
  GpuOperator-->>Operator: Provide pod GPU access through the device plugin

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the primary change: allowing the `container` GPU operator variant in the `iaas` bundle.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
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.

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch fix/gpu-operator-container-variant

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.}

The cozystack.gpu-operator PackageSource ships three variants: default, vgpu and container. The iaas bundle's variant guard accepted only the first two, so selecting container failed the render on a value the package ships, values-container.yaml configures deliberately, and the variant bats suite already covers. The exclusion was coherent when it was written and stopped being so immediately. The container variant and the guard landed within minutes of each other from parallel branches, neither an ancestor of the other, variant first. Until the guard, the bundle hardcoded the default variant and container was selected by hand-crafting a Package CR, so leaving it out of a bundle-side list cost nothing. The guard then made the bundle the variant owner and closed that route without noticing it was one; its comment describes itself as typo protection and names passthrough as the example typo. The KubeVirt side is not a bare allowlist edit. The container variant serves GPUs to pods through the device plugin and runs no VM-facing GPU stack: sandboxWorkloads and vfioManager are both off and the host driver stays bound. Both KubeVirt-side pieces the bundle wires are VM-facing — the HostDevices feature gate advertises a capability such a node cannot serve, and permittedHostDevices lists resources no sandbox device plugin registers there. Both are now emitted only for default and vgpu, and container yields the gpu-operator Package with the kubevirt component untouched. Comments and docs that described the KubeVirt mirroring as unconditional on variant, or the container variant as unmerged and unavailable, are corrected to match. Assisted-by: LLM Signed-off-by: Aleksei Sviridkin <[email protected]>

IvanHunters

Verdict

LGTM with non-blocking notes

Reviewed at 6e8566a94 against merge-base cd675e113.

Widening the allowlist is right, and skipping the KubeVirt wiring for container is a decision rather than a shortcut. I rendered the iaas bundle on both sides for all three variants: default and vgpu come out byte-identical, so nothing installed today changes shape. container fails on base at iaas.yaml:54 and renders on head. Three notes below, none blocking.

Findings

[MINOR] packages/core/platform/templates/bundles/iaas.yaml:73, the accepted-variant set is still hardcoded, and the only thing standing between it and the next drift is a comment
[MINOR] packages/core/platform/templates/bundles/iaas.yaml:76, gpu.* overrides are dropped silently under container, and nothing tells the operator
[MINOR] docs/gpu-vgpu.md:221, the docs describe the end state of container but never the transition into it

Claim mismatches

[UNVERIFIABLE] The body says the docs live in cozystack/website#685 as an issue so they cannot land ahead of this change. That is another repository and this run is hermetic, so I did not fetch it. Everything in-repo I re-derived and it holds: the PackageSource ships container, values-container.yaml configures it the way the new comment describes, hack/check-gpu-operator-variants.bats covers it in four cases, and the base guard did reject it.

Caveats

The live transition is reasoned, not run. A render cannot show the KubeVirt CR converging once HostDevices and permittedHostDevices are withdrawn, nor what a VMI already holding a host device does in that window. Both fields are chart-owned and get pruned rather than conflicted, and neither is immutable, so I see no server-side-apply hazard. That is an argument though, not evidence.
Non-string values for gpuOperatorVariant (5, true) slip past the fail and come out as a raw Go template error, incompatible types for comparison: int64 and string. Identical on the merge base, so it predates this PR. Deriving the accepted set as the first finding suggests would not fix it either, though has on a non-string at least returns false and reaches the intended message.
Nothing covers gpuOperatorVariant: container with cozystack.gpu-operator absent from enabledPackages, which is newly legal because the guard runs ahead of $gpuEnabled. I rendered it. It is fine. Coverage gap, not a defect.
The templates/repository.yaml:8 render error is a lookup guard that fails on any cluster-free render and reproduces on the merge base, and kubeconform skipped all 15 rendered resources because cozystack.io/v1alpha1 Package has no offline schema. Neither says anything about this diff.

Recommended follow-ups

Derive the accepted variant set from sources/gpu-operator.yaml, or add a cross-file equality assertion, so a fourth variant cannot ship unreachable the way container did.
Exercise the transition a static review cannot reach: install at default with the package enabled, confirm the KubeVirt CR carries HostDevices and the passthrough table, flip to container, then watch the CR converge and the HelmRelease swap its artifact ref in place instead of standing up a second release.

IvanHunters · 2026-09-07T15:04:01Z

 */ -}}
-{{- if not (or (eq $gpuVariant "default") (eq $gpuVariant "vgpu")) -}}
-{{- fail (printf "bundles.iaas.gpuOperatorVariant must be \"default\" or \"vgpu\", got %q" $gpuVariant) -}}
+{{- if not (or (eq $gpuVariant "default") (eq $gpuVariant "vgpu") (eq $gpuVariant "container")) -}}


[MINOR] the accepted-variant set is still hardcoded, and the only thing standing between it and the next drift is a comment

This PR exists because the bundle's allowlist and the PackageSource's variant list disagreed. The fix restores agreement and then documents the coupling in prose: "A variant added there needs adding here too". That is the same protection the previous round had, which is none.

sources/gpu-operator.yaml is inside the chart and reachable from templates, so the guard can derive its own accepted set and the class of bug closes permanently rather than for one release. I checked the read works before proposing it (a probe template rendering $.Files.Get "sources/gpu-operator.yaml" printed variants=[default vgpu container]), so the guard can become:

{{- $gpuVariants := list -}} {{- range (($.Files.Get "sources/gpu-operator.yaml") | fromYaml).spec.variants -}} {{- $gpuVariants = append $gpuVariants .name -}} {{- end -}} {{- if not (has $gpuVariant $gpuVariants) -}} {{- fail (printf "bundles.iaas.gpuOperatorVariant must be one of %v, got %q" $gpuVariants $gpuVariant) -}} {{- end -}}

The existing sriov and passthrough rejection cases keep passing against that shape, only the message text changes. If you would rather keep the literal list, the cheap alternative is a helm-unittest or bats case that reads both files and asserts the two sets are equal, which fails the moment a fourth variant lands on one side only.

IvanHunters · 2026-09-07T15:04:01Z

+{{- fail (printf "bundles.iaas.gpuOperatorVariant must be \"default\", \"vgpu\" or \"container\", got %q" $gpuVariant) -}}
 {{- end -}}
-{{- if $gpuEnabled }}
+{{- if and $gpuEnabled (ne $gpuVariant "container") }}


[MINOR] gpu.* overrides are dropped silently under container, and nothing tells the operator

Skipping the KubeVirt wiring for container is right. What the operator experiences is less so: someone who has gpu.permittedHostDevices.pciHostDevices populated (an AMD MI300X, an FPGA, anything they wanted advertised to VMs) and then selects container gets a clean render, a healthy platform, and their entries nowhere. The PR's own second test case pins exactly that silence, using 1002:744C as the fixture. This combination is newly reachable, since base refused container outright, so it is a new silent-ignore path rather than an inherited one.

$ helm template ... --set bundles.iaas.gpuOperatorVariant=container \ --set 'bundles.enabledPackages[0]=cozystack.gpu-operator' | grep -c pciHostDevices 0

I am not asking for a fail: the template already argues, correctly, at lines 99 to 104 that silently dropping mediatedDevices under default beats breaking an operator who keeps one shared gpu block and flips the variant. A fail here would be the harsher, less consistent choice. The chart does have a precedent for the softer signal though. templates/NOTES.txt:3 prints a WARNING: when the deletion-protection guardrail is inactive, and tests/notes_capability_gate_test.yaml holds it in place. A NOTES line along the lines of "gpuOperatorVariant is container; the entries under .gpu are not applied, that variant serves GPUs to pods only" would cost a few lines and close the gap. The same argument applies to gpu.vgpuManager and gpu.vgpuDeviceManager under default, which is pre-existing and out of scope here.

IvanHunters · 2026-09-07T15:04:01Z

 ## KubeVirt configuration

-When `cozystack.gpu-operator` is in `bundles.enabledPackages` (and not also in `bundles.disabledPackages`), the platform mirrors the chosen GPU variant into the `KubeVirt` CR automatically. There is no manual `kubectl patch` step.
+When `cozystack.gpu-operator` is in `bundles.enabledPackages` (and not also in `bundles.disabledPackages`), the platform mirrors the chosen GPU variant into the `KubeVirt` CR automatically. There is no manual `kubectl patch` step. This applies to the two VM variants only: `container` serves GPUs to pods and never to VMs, so selecting it emits the gpu-operator Package with no host-device wiring on the KubeVirt side.


[MINOR] the docs describe the end state of container but never the transition into it

Every changed comment and doc paragraph is accurate about what container renders. None of them says what happens when an existing cluster switches to it. Flipping bundles.iaas.gpuOperatorVariant from default or vgpu to container on a running cluster does not merely stop adding wiring, it withdraws HostDevices from spec.configuration.developerConfiguration.featureGates and removes spec.configuration.permittedHostDevices from the live KubeVirt CR. VMs already consuming a host-device GPU by resourceName stop being admissible on their next start or migration. The operator reading "container serves GPUs to pods and never to VMs" can reasonably read that as a statement about new workloads.

This is a documentation gap, not a code defect: the withdrawal is the intended semantics of the variant. One sentence in this section, and ideally in the release note, saying that selecting container on a cluster that already runs GPU VMs takes the gate and the permit table away from those VMs, is enough. Note that default and vgpu do not have this property between themselves, since both keep the gate and only the device table differs, so container is the first variant whose selection removes a KubeVirt feature gate.

## What this PR does ## What this PR does Two stale references in `docs/gpu-vgpu.md`. The `Last verified` line says "this PR's `vgpu` variant". The variant ships, so there is no PR left for a reader to resolve that against. The link to `packages/system/gpu-operator/examples/README.md` calls it the flow "that predates the `container` variant". That README now opens with the container variant and sends non-Talos hosts to it. The link is there because it is the Talos path. The rest is gone. #4101 rewrote the same three passages in main, and got right the one thing this PR had wrong: `bundles.iaas.gpuOperatorVariant` takes `container` now, so the `disabledPackages` plus hand-written `Package` route described here is not the way in. The rebase takes main's text for all three and keeps only the two references #4101 did not touch. ### Screenshots Docs only, no UI change. ### Downstream repositories - [x] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: - [ ] [cozystack/community](https://github.com/cozystack/community) - follow-up: Checked cozystack/website: neither line exists in `content/en/docs/next/virtualization/gpu.md` or `vgpu.md`. The `v1.2` snapshot carries its own PR-relative `Last verified` line, pointing at #2323, but that is a released version's record and out of scope here. ### Release note ```release-note NONE ```  ## Summary by CodeRabbit - **Documentation** - Updated GPU/vGPU verification details to reference the released vGPU variant. - Documented the available container variant, including deployment guidance and its scope compared with passthrough. - Updated known limitations to reflect that the container variant is shipped and does not configure host-device wiring through KubeVirt. - Clarified when KubeVirt GPU device wiring is applied based on GPU configuration settings.

The container GPU variant can now be set up through the bundle, and the docs say so. cozystack/cozystack#4101 made the `iaas` bundle accept `gpuOperatorVariant: container`, so a hand-written Package CR is no longer the only way to get it. The same change stopped rendering the KubeVirt `HostDevices` gate and `permittedHostDevices` table for `container`. Only `default` and `vgpu` get them. The container workloads page now shows the bundle values and keeps the Package CR for overrides the bundle does not expose. The passthrough and vGPU pages say which variants get the KubeVirt wiring. Only `next/` is changed. The fix is on cozystack `main` and not in any v1.6.x tag, so the `v1.6/` pages still describe the released behaviour. Closes #685

…or variant in iaas (#5073) ## What this PR does Backport of #4101 to release-1.6. - Conflict only in comments of `packages/core/platform/values.yaml`, release-1.6's KubeVirt settings are kept as they are. ### Screenshots Not a UI change. ### Downstream repositories The website v1.6 page `operations/gpu-container-workloads.md` says the iaas bundle accepts only `default` or `vgpu`, it needs an update once this ships, I will open a website issue for it. - [ ] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: ### Release note ```release-note fix(platform): accept `container` as a value for `bundles.iaas.gpuOperatorVariant`, so the gpu-operator variant the platform already ships can be selected from platform values instead of a hand-crafted Package CR. The KubeVirt `HostDevices` feature gate and `permittedHostDevices` table are now emitted for the `default` and `vgpu` variants only; `container` serves GPUs to pods and gets neither. ```

Aleksei Sviridkin (lexfrei) requested review from IvanHunters, Andrei Kvapil (kvaps), Timofei Larkin (lllamnyp) and myasnikovdaniil as code owners September 6, 2026 23:49

github-actions Bot added the area/platform Issues or PRs related to platform infrastructure (bundle, flux, talos, installer) label Sep 6, 2026

Aleksei Sviridkin (lexfrei) mentioned this pull request Sep 6, 2026

docs(gpu): container variant becomes selectable from bundle values cozystack/website#685

Closed

github-actions Bot added kind/bug Categorizes issue or PR as related to a bug size/L This PR changes 100-499 lines, ignoring generated files labels Sep 6, 2026

Aleksei Sviridkin (lexfrei) force-pushed the fix/gpu-operator-container-variant branch from 1ca93cc to 6e8566a Compare September 7, 2026 01:58

IvanHunters approved these changes Sep 7, 2026

View reviewed changes

IvanHunters mentioned this pull request Sep 7, 2026

test(tests): wire the gpu-operator suite into the unit sweep #4110

Merged

1 of 12 tasks

Aleksei Sviridkin (lexfrei) merged commit 6751633 into main Sep 7, 2026
19 checks passed

Aleksei Sviridkin (lexfrei) deleted the fix/gpu-operator-container-variant branch September 7, 2026 22:50

Aleksei Sviridkin (lexfrei) mentioned this pull request Sep 7, 2026

docs(gpu): drop two stale references in the vGPU page #4096

Merged

1 of 12 tasks

Andrei Kvapil (kvaps) mentioned this pull request Sep 21, 2026

docs(gpu): add a GPU overview page that maps the five paths cozystack/website#704

Open

Aleksei Sviridkin (lexfrei) mentioned this pull request Sep 28, 2026

docs(gpu): select the container variant from bundle values cozystack/website#714

Merged

myasnikovdaniil mentioned this pull request Oct 22, 2026

[Backport release-1.6] fix(platform): accept the container gpu-operator variant in iaas #5073

Merged

11 tasks

This was referenced Nov 10, 2026

gpu-operator: variant list is hardcoded in the iaas bundle and gpu overrides are ignored silently under container #5272

Open

gpu-operator: runtime checks still owed for #2323, #2766, #2767 and #4101 #5274

Open

Navigation Menu

Repository navigation

fix(platform): accept the container gpu-operator variant in iaas - #4101

fix(platform): accept the container gpu-operator variant in iaas#4101
Aleksei Sviridkin (lexfrei) merged 1 commit into
mainfrom
fix/gpu-operator-container-variant

Aleksei Sviridkin (lexfrei) commented Sep 6, 2026 •

edited by coderabbitai Bot

Loading

Uh oh!

coderabbitai Bot commented Sep 6, 2026 •

edited

Loading

Walkthrough

Changes

Sequence Diagram(s)

Uh oh!

IvanHunters left a comment

Uh oh!

IvanHunters Sep 7, 2026

Uh oh!

IvanHunters Sep 7, 2026

Uh oh!

IvanHunters Sep 7, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

Aleksei Sviridkin (lexfrei) commented Sep 6, 2026 • edited by coderabbitai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What this PR does

Screenshots

Downstream repositories

Release note

Summary by CodeRabbit

Uh oh!

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

Uh oh!

Walkthrough

Changes

Sequence Diagram(s)

Uh oh!

IvanHunters left a comment

Choose a reason for hiding this comment

Verdict

Findings

Claim mismatches

Caveats

Recommended follow-ups

Uh oh!

IvanHunters Sep 7, 2026

Choose a reason for hiding this comment

Uh oh!

IvanHunters Sep 7, 2026

Choose a reason for hiding this comment

Uh oh!

IvanHunters Sep 7, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Aleksei Sviridkin (lexfrei) commented Sep 6, 2026 •

edited by coderabbitai Bot

Loading

coderabbitai Bot commented Sep 6, 2026 •

edited

Loading