get services from API, removing sidecar requirement#145
get services from API, removing sidecar requirement#145
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughService discovery moved from a v2 file-based flow to a v3 API-driven flow: Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Client as Client (cmd/client)
participant Config as Config Loader
participant SDAPI as Service Discovery API (v3)
participant Services as Services Store
Client->>Config: resolve API_URL (env or default)\ncall LoadServiceURLs(apiURL)
Config->>SDAPI: create v3 client and request services
SDAPI->>Services: fetch v3 services JSON
Services-->>SDAPI: return services JSON
SDAPI-->>Config: return IBackendServices
Config-->>Client: return IBackendServices
Client->>Client: set cfg.InCluster.ServerUrl if synchronizer URL present
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@config/config.go`:
- Around line 130-135: LoadServiceURLs(string) now expects an API URL but
callers/tests (e.g., config_test.go) still pass file paths like
"../configuration/services.json" and the env key "SERVICES", breaking CI; either
migrate those call sites/tests to use an actual service-discovery API URL (spin
up a test HTTP discovery stub and call v3.NewServiceDiscoveryClientV3 with that
URL) or add a compatibility branch in LoadServiceURLs: detect a file path
(os.Stat succeeds or strings.HasPrefix "./" or "../"), and when detected read
the JSON and call the existing servicediscovery logic for file inputs (implement
a helper such as servicediscovery.GetServicesFromFile and invoke it instead of
NewServiceDiscoveryClientV3), keeping the original servicediscovery.GetServices
call path for real API URLs so tests and callers continue to work.
In `@go.mod`:
- Line 106: Upgrade the module requirement for github.com/docker/docker from
v28.5.0+incompatible to v29.3.1 or later to address the reported vulnerabilities
(CVE-2026-33997 and CVE-2026-34040); either update the require line for
github.com/docker/docker to v29.3.1+, or add an explicit override/replace in
go.mod if the version is pulled via a parent dependency (e.g.,
testcontainers/docker-related deps), then run go get
github.com/docker/docker@v29.3.1 (or newer) and go mod tidy to update the lock
files and ensure compatibility, and run the test suite to confirm nothing
breaks.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: ea28986e-4991-4ba0-a013-a54158e0c7f5
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (3)
cmd/client/main.goconfig/config.gogo.mod
| github.com/docker/cli v28.3.3+incompatible // indirect | ||
| github.com/docker/docker v28.3.3+incompatible // indirect | ||
| github.com/docker/cli v29.2.0+incompatible // indirect | ||
| github.com/docker/docker v28.5.0+incompatible // indirect |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is the first patched version of github.com/docker/docker for GO-2026-4883 and GO-2026-4887 (also GHSA-pxq6-2prw-chj9 and GHSA-x744-4wpc-v9h2)?
💡 Result:
The first patched version of github.com/docker/docker (Moby project) for GHSA-pxq6-2prw-chj9 (plugin privilege validation bypass, CVE-2026-33997) and GHSA-x744-4wpc-v9h2 (AuthZ plugin bypass with oversized request body, CVE-2026-34040) is v29.3.1. Both advisories explicitly state affected versions are < 29.3.1 and patched versions are 29.3.1. GO-2026-4883 and GO-2026-4887 are likely the corresponding Go vulnerability database IDs for these issues, as indicated by the vulndb issue tracking GHSA-pxq6-2prw-chj9 and similar patterns for the other. This aligns with Docker Engine v29.3.0 release in Docker Desktop 4.66.0 (2026-03-23) and v29.3.1 in 4.66.1 (2026-03-26).
Citations:
- 1: GHSA-pxq6-2prw-chj9
- 2: GHSA-x744-4wpc-v9h2
- 3: x/vulndb: potential Go vuln in github.com/moby/moby/v2: GHSA-pxq6-2prw-chj9 golang/vulndb#4883
- 4: https://vulnerability.circl.lu/vuln/ghsa-x744-4wpc-v9h2
Upgrade github.com/docker/docker from v28.5.0 to v29.3.1 or later to fix high-severity vulnerabilities.
Current version v28.5.0+incompatible is affected by:
- GHSA-pxq6-2prw-chj9 (plugin privilege validation bypass, CVE-2026-33997)
- GHSA-x744-4wpc-v9h2 (AuthZ plugin bypass with oversized request body, CVE-2026-34040)
Patched in v29.3.1. Update via parent dependency chain (testcontainers/docker-related deps) or add an explicit override after validating compatibility.
🧰 Tools
🪛 OSV Scanner (2.3.5)
[HIGH] 106-106: github.com/docker/docker 28.5.0+incompatible: Moby has an Off-by-one error in its plugin privilege validation in github.com/docker/docker
(GO-2026-4883)
[HIGH] 106-106: github.com/docker/docker 28.5.0+incompatible: Moby has AuthZ plugin bypass when provided oversized request bodies in github.com/docker/docker
(GO-2026-4887)
[HIGH] 106-106: github.com/docker/docker 28.5.0+incompatible: Moby has an Off-by-one error in its plugin privilege validation
[HIGH] 106-106: github.com/docker/docker 28.5.0+incompatible: Moby has AuthZ plugin bypass when provided oversized request bodies
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@go.mod` at line 106, Upgrade the module requirement for
github.com/docker/docker from v28.5.0+incompatible to v29.3.1 or later to
address the reported vulnerabilities (CVE-2026-33997 and CVE-2026-34040); either
update the require line for github.com/docker/docker to v29.3.1+, or add an
explicit override/replace in go.mod if the version is pulled via a parent
dependency (e.g., testcontainers/docker-related deps), then run go get
github.com/docker/docker@v29.3.1 (or newer) and go mod tidy to update the lock
files and ensure compatibility, and run the test suite to confirm nothing
breaks.
Signed-off-by: Matthias Bertschy <matthias.bertschy@gmail.com>
matthyx
force-pushed
the
disco-client
branch
2 times, most recently
from
8de8a5e to
1be3a79
Compare
|
Summary:
|
There was a problem hiding this comment.
🧹 Nitpick comments (1)
config/config_test.go (1)
126-137: Make the stub reject the wrong request.The v3 client hits
GET /api/v3/servicediscovery, but this handler returns a valid payload for every request. If the method or path regresses, the test still passes; asserting both here would turn this into a real contract test for the new HTTP discovery flow. (pkg.go.dev)Possible tweak
srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { + if !assert.Equal(t, http.MethodGet, r.Method) { + return + } + if !assert.Equal(t, "/api/v3/servicediscovery", r.URL.Path) { + return + } + w.Header().Set("Content-Type", "application/json") _ = json.NewEncoder(w).Encode(map[string]interface{}{🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@config/config_test.go` around lines 126 - 137, The test stub in the httptest.NewServer handler currently returns a valid payload for any request; update the handler (the anonymous http.HandlerFunc used to create srv) to verify r.Method == "GET" and r.URL.Path (expected "/api/v3/servicediscovery") and return a non-200 response or call t.Fatalf/t.Errorf when those don't match so the test fails on wrong method/path; keep the existing JSON response only when both checks pass.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@config/config_test.go`:
- Around line 126-137: The test stub in the httptest.NewServer handler currently
returns a valid payload for any request; update the handler (the anonymous
http.HandlerFunc used to create srv) to verify r.Method == "GET" and r.URL.Path
(expected "/api/v3/servicediscovery") and return a non-200 response or call
t.Fatalf/t.Errorf when those don't match so the test fails on wrong method/path;
keep the existing JSON response only when both checks pass.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 6b88f128-d3b8-445b-b876-4b56102c99ea
⛔ Files ignored due to path filters (2)
go.sumis excluded by!**/*.sumtests/go.sumis excluded by!**/*.sum
📒 Files selected for processing (6)
.github/workflows/pr-created.yamlcmd/client/main.goconfig/config.goconfig/config_test.gogo.modtests/go.mod
✅ Files skipped from review due to trivial changes (1)
- .github/workflows/pr-created.yaml
🚧 Files skipped from review as they are similar to previous changes (1)
- cmd/client/main.go
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
tests/go.mod (1)
215-215:⚠️ Potential issue | 🟠 MajorUpgrade
go-jose/go-jose/v4from v4.1.3 to v4.1.4 or later.v4.1.3 is vulnerable to GHSA-78h2-9frx-2jm8, a JWE decryption panic (CVE-2026-34986). The first patched version is v4.1.4.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/go.mod` at line 215, Update the vulnerable dependency declaration in tests/go.mod by bumping the module version for github.com/go-jose/go-jose/v4 from v4.1.3 to v4.1.4 (or later) and then run Go module tooling (e.g., go get github.com/go-jose/go-jose/v4@v4.1.4 and go mod tidy) to propagate the change; ensure the tests/go.mod entry and go.sum are updated accordingly.
🧹 Nitpick comments (1)
tests/go.mod (1)
14-16: Verify test module API skew vs root module (messagingonly).Tests depend on
github.com/kubescape/messagingv0.0.101 while root uses v0.0.33. Storage is already aligned at v0.0.258 in both. The significant messaging version skew could validate a different API shape in integration tests if root remains at v0.0.33.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/go.mod` around lines 14 - 16, Tests are pulling github.com/kubescape/messaging at v0.0.101 while the root module uses v0.0.33, which can cause API skew; update tests/go.mod to align the messaging dependency with the root (use github.com/kubescape/messaging v0.0.33) or add a replace directive in tests/go.mod pointing github.com/kubescape/messaging => github.com/kubescape/messaging v0.0.33, then run go mod tidy to ensure the test module uses the same messaging API as the root; verify no other imports rely on v0.0.101 afterwards.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@tests/go.mod`:
- Around line 20-23: Update the k8s.io/kube-aggregator module version to match
the other Kubernetes modules (change k8s.io/kube-aggregator v0.29.4 to v0.35.0)
in the tests/go.mod so apiregistration types are compatible with k8s.io/api,
apimachinery, and client-go; after editing the module version run go mod tidy to
refresh the dependency graph and verify tests compile.
- Line 186: Update the indirect module version for github.com/docker/docker from
v28.5.2 to v29.3.1 (or later) in go.mod (the dependency entry
"github.com/docker/docker"), then refresh the lockfile by running the Go module
tooling (e.g., go get github.com/docker/docker@v29.3.1 and go mod tidy) so
go.sum is regenerated with the patched release. Ensure the version string and
the indirect comment are updated accordingly.
---
Outside diff comments:
In `@tests/go.mod`:
- Line 215: Update the vulnerable dependency declaration in tests/go.mod by
bumping the module version for github.com/go-jose/go-jose/v4 from v4.1.3 to
v4.1.4 (or later) and then run Go module tooling (e.g., go get
github.com/go-jose/go-jose/v4@v4.1.4 and go mod tidy) to propagate the change;
ensure the tests/go.mod entry and go.sum are updated accordingly.
---
Nitpick comments:
In `@tests/go.mod`:
- Around line 14-16: Tests are pulling github.com/kubescape/messaging at
v0.0.101 while the root module uses v0.0.33, which can cause API skew; update
tests/go.mod to align the messaging dependency with the root (use
github.com/kubescape/messaging v0.0.33) or add a replace directive in
tests/go.mod pointing github.com/kubescape/messaging =>
github.com/kubescape/messaging v0.0.33, then run go mod tidy to ensure the test
module uses the same messaging API as the root; verify no other imports rely on
v0.0.101 afterwards.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: fab94f31-df8f-441d-ab9f-7bd73b84060a
⛔ Files ignored due to path filters (1)
tests/go.sumis excluded by!**/*.sum
📒 Files selected for processing (2)
.github/workflows/pr-created.yamltests/go.mod
✅ Files skipped from review due to trivial changes (1)
- .github/workflows/pr-created.yaml
| k8s.io/api v0.35.0 | ||
| k8s.io/apimachinery v0.35.0 | ||
| k8s.io/client-go v0.35.0 | ||
| k8s.io/kube-aggregator v0.29.4 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify Kubernetes module-family skew in tests/go.mod
rg -n '^\s*k8s\.io/(api|apimachinery|client-go|kube-aggregator)\s+v' tests/go.modRepository: kubescape/synchronizer
Length of output: 184
🏁 Script executed:
# Check if kube-aggregator is imported anywhere in the tests
rg -i 'kube-aggregator|aggregator' tests/ --type goRepository: kubescape/synchronizer
Length of output: 329
🏁 Script executed:
# Check the full tests/go.mod to see if kube-aggregator is direct or transitive
cat tests/go.mod | head -50Repository: kubescape/synchronizer
Length of output: 2391
🏁 Script executed:
# Check the go.sum for kube-aggregator references to understand the dependency chain
rg 'k8s.io/kube-aggregator' tests/go.sumRepository: kubescape/synchronizer
Length of output: 230
Align Kubernetes module minors (kube-aggregator is out of family).
Line 23 pins k8s.io/kube-aggregator v0.29.4 while Lines 20-22 are on v0.35.0. The test code actively imports apiregistration types from kube-aggregator, and this 6-minor-version skew can cause type incompatibilities and runtime failures with the k8s.io API machinery and client libraries.
Suggested minimal fix
- k8s.io/kube-aggregator v0.29.4
+ k8s.io/kube-aggregator v0.35.0📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| k8s.io/api v0.35.0 | |
| k8s.io/apimachinery v0.35.0 | |
| k8s.io/client-go v0.35.0 | |
| k8s.io/kube-aggregator v0.29.4 | |
| k8s.io/api v0.35.0 | |
| k8s.io/apimachinery v0.35.0 | |
| k8s.io/client-go v0.35.0 | |
| k8s.io/kube-aggregator v0.35.0 |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@tests/go.mod` around lines 20 - 23, Update the k8s.io/kube-aggregator module
version to match the other Kubernetes modules (change k8s.io/kube-aggregator
v0.29.4 to v0.35.0) in the tests/go.mod so apiregistration types are compatible
with k8s.io/api, apimachinery, and client-go; after editing the module version
run go mod tidy to refresh the dependency graph and verify tests compile.
| github.com/docker/cli v29.2.0+incompatible // indirect | ||
| github.com/docker/distribution v2.8.3+incompatible // indirect | ||
| github.com/docker/docker v28.3.3+incompatible // indirect | ||
| github.com/docker/docker v28.5.2+incompatible // indirect |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is the first patched version for GO-2026-4883 and GO-2026-4887 affecting github.com/docker/docker, and which version should replace v28.5.2+incompatible?
💡 Result:
The first patched version for both GO-2026-4883 and GO-2026-4887 in github.com/docker/docker is v28.5.3-0.20260325154711-31a1689cb0a1+incompatible. The version that should replace v28.5.2+incompatible is v28.5.3-0.20260325154711-31a1689cb0a1+incompatible.
Citations:
🌐 Web query:
GO-2026-4883 GO-2026-4887 github.com/docker/docker security advisory CVE
💡 Result:
GO-2026-4883 and GO-2026-4887 are recent Go security advisories (published April 2, 2026) affecting github.com/docker/docker (also mirrored as github.com/moby/moby). GO-2026-4883 (CVE-2026-33997, GHSA-pxq6-2prw-chj9): Moby has an off-by-one error in its plugin privilege validation. GO-2026-4887 (CVE-2026-34040, GHSA-x744-4wpc-v9h2): Moby has an AuthZ plugin bypass when provided oversized request bodies. These are unreviewed reports listed on pkg.go.dev/vuln/list. No detailed descriptions, affected versions, or patches were found in the search results. Check official Moby/Docker security advisories and pkg.go.dev/vuln/GO-2026-4883 and pkg.go.dev/vuln/GO-2026-4887 for updates. Upgrade to latest versions of github.com/docker/docker and github.com/moby/moby.
Citations:
🌐 Web query:
docker/docker v28.5.3 CVE-2026 AuthZ bypass plugin privilege validation
💡 Result:
Docker Engine (Moby/moby) v28.5.3 does not have a specific CVE assigned with ID starting "CVE-2026" directly tied to it in official sources. However, two recent relevant vulnerabilities match the description of AuthZ bypass and plugin privilege validation: 1. CVE-2026-34040 (GHSA-x744-4wpc-v9h2): AuthZ plugin bypass using oversized request bodies. This is an incomplete fix for the earlier CVE-2024-41110 regression. Affected versions: < 29.3.1. Patched in v29.3.1 (released 2026-03-25). Severity: High (CVSS 8.8). Impact: Attackers with low privileges can bypass AuthZ plugins by crafting API requests without bodies, leading to unauthorized actions if plugins inspect request bodies. v28.5.3 (part of v28 series, latest ~2025) is affected since patches are only in v29.3.1. 2. CVE-2026-33997 (GHSA-pxq6-2prw-chj9): Off-by-one error in plugin privilege validation during docker plugin install. Affected versions: < 29.3.1. Patched in v29.3.1. Severity: Moderate (CVSS 6.8). Impact: Malicious plugins can gain unintended privileges (e.g., device access) due to faulty comparison logic, even for single-privilege plugins. v28.5.3 is affected. No evidence of v28.5.3 release notes mentioning these CVEs; v28 series tops at ~28.5.2 (2025-11), predating the March 2026 disclosures/patches in v29.3.1. Upgrade to Docker Engine >= v29.3.1 to mitigate. If not using AuthZ plugins or installing untrusted plugins, risk is lower. No exact "CVE-2026" matching the query verbatim, but these fit the description precisely.
Citations:
- 1: https://advisories.gitlab.com/pkg/golang/github.com/docker/docker/CVE-2026-34040/
- 2: GHSA-x744-4wpc-v9h2
- 3: GHSA-x744-4wpc-v9h2
- 4: https://nvd.nist.gov/vuln/detail/CVE-2026-33997
- 5: https://advisories.gitlab.com/pkg/golang/github.com/moby/moby/v2/CVE-2026-33997/
- 6: GHSA-pxq6-2prw-chj9
- 7: https://docs.docker.com/engine/release-notes/
- 8: https://docs.docker.com/engine/release-notes
🏁 Script executed:
cat -n tests/go.mod | sed -n '180,195p'Repository: kubescape/synchronizer
Length of output: 1079
Bump github.com/docker/docker to v29.3.1 or later to patch high-severity vulnerabilities.
Version v28.5.2 is affected by CVE-2026-34040 (AuthZ plugin bypass, CVSS 8.8) and CVE-2026-33997 (plugin privilege validation off-by-one error, CVSS 6.8). These are only patched in v29.3.1+; v28.x series does not contain the fixes. Update the dependency and refresh go.sum.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@tests/go.mod` at line 186, Update the indirect module version for
github.com/docker/docker from v28.5.2 to v29.3.1 (or later) in go.mod (the
dependency entry "github.com/docker/docker"), then refresh the lockfile by
running the Go module tooling (e.g., go get github.com/docker/docker@v29.3.1 and
go mod tidy) so go.sum is regenerated with the patched release. Ensure the
version string and the indirect comment are updated accordingly.
|
Summary:
|
- Upgrade event-ingester-service to v0.1.1-0.20260403130541-5bd52e351584 which migrates large testdata to LFS, keeping the Go module zip under the 524 MB limit - Upgrade postgres-connector to v0.0.1296 to align with utils-k8s-go API changes (NetworkPolicyPodSelectorMatchLabels) - Set GIT_LFS_SKIP_SMUDGE=1 in CI so go mod download receives LFS pointer files instead of smudged content, preventing the zip size limit from being hit during module download Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: Matthias Bertschy <matthias.bertschy@gmail.com>
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
tests/go.mod (1)
215-215:⚠️ Potential issue | 🟠 MajorUpgrade
github.com/go-jose/go-jose/v4to v4.1.4 to resolve a HIGH severity panic vulnerability (GHSA-78h2-9frx-2jm8 / CVE-2026-34986).Line 215 pins v4.1.3, which is vulnerable to JWE decryption panics that can lead to denial of service. The vulnerability is fixed in v4.1.4. Bump the version and run
go mod tidy.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/go.mod` at line 215, Update the indirect dependency github.com/go-jose/go-jose/v4 from v4.1.3 to v4.1.4 in the go.mod entry (the line containing "github.com/go-jose/go-jose/v4 v4.1.3 // indirect"), then run `go mod tidy` to refresh the module graph and vendor files; after that, run the test suite or `go list -m all` to verify the new v4.1.4 version is picked up and the HIGH severity panic vulnerability is resolved.
♻️ Duplicate comments (2)
tests/go.mod (2)
186-186:⚠️ Potential issue | 🟠 MajorUpgrade
github.com/docker/dockerfromv28.5.2+incompatibledue to high-severity advisories.Line 186 keeps a version reported as vulnerable (AuthZ bypass + plugin privilege validation issue). Please bump to a patched release and refresh
go.sum.Suggested update
- github.com/docker/docker v28.5.2+incompatible // indirect + github.com/docker/docker v29.3.1+incompatible // indirect#!/bin/bash # Confirm pinned version in go.mod rg -n 'github\.com/docker/docker\s+v' tests/go.mod # Check OSV records for github.com/docker/docker curl -s https://api.osv.dev/v1/query -H 'Content-Type: application/json' \ -d '{"package":{"name":"github.com/docker/docker","ecosystem":"Go"},"version":"v28.5.2+incompatible"}' | jq .🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/go.mod` at line 186, The go.mod entry for module github.com/docker/docker is pinned at v28.5.2+incompatible which has known high-severity advisories; update that dependency to a patched release by selecting the latest non-vulnerable tag (replace v28.5.2+incompatible with the secure version) and then refresh modules by running a module update (e.g., go get github.com/docker/docker@<patched-version>) and tidy/sync the lockfile (go mod tidy / go.sum update) so go.sum is regenerated; ensure the updated version replaces the existing github.com/docker/docker line and that tests compile against the new release.
23-23:⚠️ Potential issue | 🟠 MajorAlign
k8s.io/kube-aggregatorwith the rest of the Kubernetes minor versions.Line 23 is still on
v0.29.4while Lines 20–22 are onv0.35.0. This skew can cause type/runtime incompatibilities in k8s client and API machinery usage.Suggested minimal fix
- k8s.io/kube-aggregator v0.29.4 + k8s.io/kube-aggregator v0.35.0#!/bin/bash # Verify k8s module family alignment in tests/go.mod rg -n '^\s*k8s\.io/(api|apimachinery|client-go|kube-aggregator)\s+v' tests/go.mod🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/go.mod` at line 23, The k8s module versions in tests/go.mod are skewed: update the k8s.io/kube-aggregator entry (currently v0.29.4) to match the other Kubernetes minor versions (v0.35.0) so it aligns with k8s.io/api, k8s.io/apimachinery and k8s.io/client-go; edit the k8s.io/kube-aggregator line to v0.35.0 and run your normal Go tooling (go mod tidy / go list -m all) to verify there are no remaining mismatches.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@tests/go.mod`:
- Line 215: Update the indirect dependency github.com/go-jose/go-jose/v4 from
v4.1.3 to v4.1.4 in the go.mod entry (the line containing
"github.com/go-jose/go-jose/v4 v4.1.3 // indirect"), then run `go mod tidy` to
refresh the module graph and vendor files; after that, run the test suite or `go
list -m all` to verify the new v4.1.4 version is picked up and the HIGH severity
panic vulnerability is resolved.
---
Duplicate comments:
In `@tests/go.mod`:
- Line 186: The go.mod entry for module github.com/docker/docker is pinned at
v28.5.2+incompatible which has known high-severity advisories; update that
dependency to a patched release by selecting the latest non-vulnerable tag
(replace v28.5.2+incompatible with the secure version) and then refresh modules
by running a module update (e.g., go get
github.com/docker/docker@<patched-version>) and tidy/sync the lockfile (go mod
tidy / go.sum update) so go.sum is regenerated; ensure the updated version
replaces the existing github.com/docker/docker line and that tests compile
against the new release.
- Line 23: The k8s module versions in tests/go.mod are skewed: update the
k8s.io/kube-aggregator entry (currently v0.29.4) to match the other Kubernetes
minor versions (v0.35.0) so it aligns with k8s.io/api, k8s.io/apimachinery and
k8s.io/client-go; edit the k8s.io/kube-aggregator line to v0.35.0 and run your
normal Go tooling (go mod tidy / go list -m all) to verify there are no
remaining mismatches.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 279348f0-ba5b-4d2d-b222-1fd28b2db2d6
⛔ Files ignored due to path filters (1)
tests/go.sumis excluded by!**/*.sum
📒 Files selected for processing (3)
.github/workflows/pr-created.yamltests/go.modtests/synchronizer_integration_test.go
✅ Files skipped from review due to trivial changes (1)
- .github/workflows/pr-created.yaml
🚧 Files skipped from review as they are similar to previous changes (1)
- tests/synchronizer_integration_test.go
|
Summary:
|
… in tests The event-ingester-service added SetSIEMProducer to the ConfigServiceConnector interface. The csMock in integration tests embeds the interface (which is nil), causing a panic when NewSessionHandler calls SetSIEMProducer on it. Added a no-op implementation to csMock. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Summary:
|
When 17 component test jobs run in parallel, they all simultaneously call the GitHub API to fetch db-migrations files, causing 403 rate limit errors for the shared service account. Added a random jitter (0-10s) before the first attempt and exponential backoff retry (30s initial, 5m max, 15m total) to spread out the requests and recover from transient rate limit failures. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Summary:
|
The PulsarMessageReader.readerLoop called logger.Fatal (which calls os.Exit(1)) whenever the pulsar reader returned any error, including the expected "ConsumerClosed" error during test teardown. This caused all component test assertions to be skipped because the process exited before they ran. Two fixes: 1. pulsar.go: readerLoop now returns gracefully on context cancellation or consumer-closed errors instead of calling Fatal. 2. tests/synchronizer_integration_test.go: tearDown now cancels all server/client contexts before closing the pulsar client, ensuring goroutines receive context.Canceled (not ConsumerClosed) and exit cleanly. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Summary:
|
…limits The GitHub API rate limit reset window can be up to ~27 minutes when 17 parallel test jobs fire simultaneously. Two changes to handle this: 1. tests: increase migration retry MaxElapsedTime from 15m to 35m so the exponential backoff has enough time to wait out the full rate limit reset cycle. 2. .github/workflows: increase component test --timeout from 20m to 40m so the test runner doesn't kill the process before the migration retry succeeds. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Summary:
|
…tener Replace ListenAndServe with pre-binding via net.Listen so that port binding errors are returned from Start() rather than calling Fatal (os.Exit). Also replace Fatal with Error for any subsequent server errors, with graceful context-cancellation handling. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Summary:
|
…imiting Instead of retrying with backoff when the GitHub API rate limit is hit by 17 parallel matrix jobs, clone the db-migrations repo once per job via HTTPS and point LOCAL_FILE_MIGRATION_PATH at the local copy. This makes migrations instant and deterministic regardless of API quota. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Summary:
|
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Summary:
|
The 10s fixed sleep was insufficient for Pulsar to fully restart. Replace with a poll on the /admin/v2/clusters endpoint (max 2 minutes) to ensure the broker is accepting connections before checking results. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Summary:
|
…nection After Pulsar admin is ready, the Pulsar client needs additional time to detect the broker is back, recreate subscriptions, and for the synchronizer to retransmit and ingest the pending message into Postgres. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Summary:
|
…r restart After Pulsar restarts, clients need variable time to reconnect and for the ingester to process the pending applicationprofile message. Replace the fixed 30s sleep + single check with a backoff retry loop (up to 60s) so the assertion passes as soon as the object lands in Postgres. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Summary:
|
1 participant
Summary by CodeRabbit
New Features
Tests
Chores