fix: update proton and migrate to runtime proto validation#1490
fix: update proton and migrate to runtime proto validation#1490
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughSummary by CodeRabbit
WalkthroughRemoved per-request protobuf validation calls from handlers and CLI commands, added a centralized connect validation interceptor, updated proto-generation commit and buf validation config, and bumped Go toolchain and multiple module dependencies. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
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 |
ravisuhag
force-pushed
the
chore/update-proton-gen-code
branch
from
d75bea2 to
22d2368
Compare
ravisuhag
changed the title
![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
🧹 Nitpick comments (1)
pkg/server/server.go (1)
157-166: Consider interceptor ordering for fail-fast behavior.The
validateInterceptoris placed after authentication and authorization interceptors. This means:
- Invalid requests from authenticated users still consume auth resources before failing validation
- However, this prevents leaking validation error details to unauthenticated callers
If early rejection of malformed requests is preferred (fail-fast), consider moving
validateInterceptorearlier in the chain (e.g., afterUnaryConnectErrorResponseInterceptor). If preventing information disclosure to unauthenticated users is the priority, the current placement is appropriate.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 21822891-ef0f-41ce-b1e2-9c7db0e6fb10
⛔ Files ignored due to path filters (4)
go.sumis excluded by!**/*.sumproto/v1beta1/admin.pb.validate.gois excluded by!proto/**proto/v1beta1/frontier.pb.validate.gois excluded by!proto/**proto/v1beta1/models.pb.validate.gois excluded by!proto/**
📒 Files selected for processing (15)
buf.gen.yamlcmd/group.gocmd/organization.gocmd/permission.gocmd/policy.gocmd/project.gocmd/role.gocmd/user.gogo.modinternal/api/v1beta1connect/audit_record.gointernal/api/v1beta1connect/organization.gointernal/api/v1beta1connect/organization_pats.gointernal/api/v1beta1connect/session.gointernal/api/v1beta1connect/user_pat.gopkg/server/server.go
💤 Files with no reviewable changes (12)
- cmd/role.go
- cmd/organization.go
- cmd/user.go
- cmd/permission.go
- cmd/group.go
- cmd/project.go
- cmd/policy.go
- internal/api/v1beta1connect/user_pat.go
- internal/api/v1beta1connect/organization_pats.go
- internal/api/v1beta1connect/organization.go
- internal/api/v1beta1connect/session.go
- internal/api/v1beta1connect/audit_record.go
🚧 Files skipped from review as they are similar to previous changes (1)
- buf.gen.yaml
| github.com/stretchr/testify v1.11.1 | ||
| github.com/stripe/stripe-go/v79 v79.5.0 | ||
| github.com/ua-parser/uap-go v0.0.0-20250917011043-9c86a9b0f8f0 | ||
| go.opentelemetry.io/otel/sdk/metric v1.37.0 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check for patched otel/sdk versions
echo "=== Checking OpenTelemetry SDK vulnerability advisory ==="
gh api graphql -f query='
{
securityVulnerabilities(first: 5, ecosystem: GO, package: "go.opentelemetry.io/otel/sdk") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'
echo ""
echo "=== Available otel/sdk versions ==="
curl -s "https://proxy.golang.org/go.opentelemetry.io/otel/sdk/@v/list" | tail -10Repository: raystack/frontier
Length of output: 395
🏁 Script executed:
#!/bin/bash
# Get full list of otel/sdk/metric versions (not just last 10)
echo "=== Full list of go.opentelemetry.io/otel/sdk/metric versions ==="
curl -s "https://proxy.golang.org/go.opentelemetry.io/otel/sdk/metric/@v/list"
echo ""
echo "=== Check if v1.37.0 exists ==="
curl -s -I "https://proxy.golang.org/go.opentelemetry.io/otel/sdk/metric/@v/v1.37.0.info"Repository: raystack/frontier
Length of output: 1277
🌐 Web query:
GHSA-9h8m-3fm2-qjrq vulnerability OpenTelemetry PATH hijacking
💡 Result:
GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) is a high-severity vulnerability (CVSS 7.0) in the OpenTelemetry Go SDK (go.opentelemetry.io/otel/sdk), affecting versions 1.21.0 to 1.39.0. It enables arbitrary code execution via PATH hijacking on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the 'ioreg' system command without specifying a full path, relying on the PATH environment variable. A local attacker with low privileges who can modify PATH (e.g., by placing a malicious 'ioreg' executable in a directory prioritized in PATH) can achieve arbitrary code execution in the application's context. Associated with CWE-426 (Untrusted Search Path). Patched in commit d45961b, released in v1.40.0 (February 2026). Upgrade to v1.40.0 or later. As of 2026-03-31, the patch is available. Official sources: GitHub Advisory Database, OpenTelemetry Go security advisory, NVD.
Citations:
- 1: GHSA-9h8m-3fm2-qjrq
- 2: https://osv.dev/vulnerability/GHSA-9h8m-3fm2-qjrq
- 3: GHSA-9h8m-3fm2-qjrq
- 4: https://nvd.nist.gov/vuln/detail/CVE-2026-24051
🌐 Web query:
CVE OpenTelemetry SDK metric PATH hijacking vulnerability 2024 2025
💡 Result:
No vulnerability matching "OpenTelemetry SDK metric PATH hijacking" was found in searches across 2024-2025 or later. The closest match is CVE-2026-24051 (disclosed Feb 2026), a PATH hijacking vulnerability in the OpenTelemetry Go SDK (go.opentelemetry.io/otel/sdk/resource, versions >=1.21.0, <=1.39.0) affecting macOS/Darwin systems. It allows arbitrary code execution via untrusted PATH when executing the 'ioreg' command in sdk/resource/host_id.go for resource detection (host ID). CVSS 3.1: 7.0 (High). Patched in v1.40.0 via commit d45961bcda453fcbdb6469c22d6e88a1f9970a53. This issue is unrelated to metrics or path traversal in metric handling. Other OpenTelemetry vulnerabilities (e.g., CVE-2023-25151 for high-cardinality metrics DoS in otelhttp, CVE-2024-36129 for DoS in Collector, CVE-2023-43810 for unbound metrics cardinality) do not involve PATH hijacking or path traversal in metrics.
Citations:
- 1: GHSA-9h8m-3fm2-qjrq
- 2: https://security.snyk.io/vuln/SNYK-MINIMOSLATEST-OPENTELEMETRYCOLLECTORCONTRIBCONFIG-15365804
- 3: https://opentelemetry.io/docs/security/cve/
- 4: https://cvefeed.io/vuln/detail/CVE-2026-24051
- 5: https://vulert.com/vuln-db/CVE-2026-24051
- 6: https://advisories.gitlab.com/pkg/golang/go.opentelemetry.io/otel/sdk/resource/CVE-2026-24051/
- 7: https://app.opencve.io/cve/?vendor=opentelemetry
- 8: https://vulert.com/vuln-db/opentelemetry-go-sdk-vulnerable-to-arbitrary-code-execution-via-path-hijacking-in-go-opentelemetry-i-
- 9: https://opentelemetry.io/blog/2024/cve-2024-36129
- 10: https://security.snyk.io/vuln/SNYK-GOLANG-GITHUBCOMOPENTELEMETRYOPENTELEMETRYGOSDKRESOURCE-15182757
- 11: https://nvd.nist.gov/vuln/detail/cve-2023-25151
- 12: https://www.tenable.com/cve/CVE-2026-24051
🏁 Script executed:
#!/bin/bash
# Check the go.mod file in the repo to see all OpenTelemetry dependencies
echo "=== OpenTelemetry dependencies in go.mod ==="
grep -i "go.opentelemetry" go.mod
echo ""
echo "=== Checking otel/sdk/metric v1.37.0 dependencies ==="
curl -s "https://proxy.golang.org/go.opentelemetry.io/otel/sdk/metric/@v/v1.37.0.mod" | head -20Repository: raystack/frontier
Length of output: 1244
🌐 Web query:
go.opentelemetry.io/otel/sdk/metric v1.37.0 dependencies PATH hijacking vulnerability
💡 Result:
Yes, go.opentelemetry.io/otel/sdk/metric v1.37.0 is vulnerable to the PATH hijacking vulnerability CVE-2026-24051 (GHSA-9h8m-3fm2-qjrq, GO-2026-4394). This affects the broader OpenTelemetry Go SDK (go.opentelemetry.io/otel/sdk) versions >=v1.21.0 and <v1.40.0, specifically due to untrusted search path usage when executing the 'ioreg' command on macOS/Darwin systems in sdk/resource/host_id.go, allowing local authenticated attackers to achieve arbitrary code execution by modifying the PATH environment variable. The sdk/metric module depends on the vulnerable go.opentelemetry.io/otel/sdk (as shown in pkg.go.dev listings for similar versions like v1.38.0, which lists go.opentelemetry.io/otel/sdk v1.38.0). Version alignment across OpenTelemetry Go modules means v1.37.0 of sdk/metric pulls in the vulnerable sdk v1.37.0. The fix is in v1.40.0 via commit d45961b, which specifies the full path for the ioreg command. CVSS v3.1: 7.0 High (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Patched in v1.40.0. Upgrade to v1.40.0 or later. Workarounds: avoid running on macOS/Darwin or ensure PATH cannot be modified by untrusted users.
Citations:
- 1: https://vulert.com/vuln-db/opentelemetry-go-sdk-vulnerable-to-arbitrary-code-execution-via-path-hijacking-in-go-opentelemetry-i-
- 2: https://scout.docker.com/vulnerabilities/id/CVE-2026-24051?n=sdk&ns=go.opentelemetry.io%2Fotel&s=github&t=golang&vr=%3E%3D1.21.0%2C%3C1.40.0
- 3: GHSA-9h8m-3fm2-qjrq
- 4: https://osv.dev/vulnerability/CVE-2026-24051
- 5: https://pkg.go.dev/vuln/GO-2026-4394
- 6: https://newreleases.io/project/github/open-telemetry/opentelemetry-go/release/v1.40.0
Upgrade go.opentelemetry.io/otel/sdk/metric to v1.40.0 or later.
go.opentelemetry.io/otel/sdk/metric v1.37.0 contains a HIGH severity vulnerability (GHSA-9h8m-3fm2-qjrq / CVE-2026-24051) that enables arbitrary code execution via PATH hijacking on macOS/Darwin systems. The vulnerability exists in the base SDK's resource detection code, which executes the 'ioreg' command without specifying a full path. A patched version (v1.40.0+) is available.
🧰 Tools
🪛 OSV Scanner (2.3.5)
[HIGH] 50-50: go.opentelemetry.io/otel/sdk 1.37.0: OpenTelemetry Go SDK Vulnerable to Arbitrary Code Execution via PATH Hijacking in go.opentelemetry.io/otel/sdk
(GO-2026-4394)
[HIGH] 50-50: go.opentelemetry.io/otel/sdk 1.37.0: OpenTelemetry Go SDK Vulnerable to Arbitrary Code Execution via PATH Hijacking
| google.golang.org/protobuf v1.36.6 | ||
| golang.org/x/sync v0.17.0 | ||
| google.golang.org/genproto/googleapis/api v0.0.0-20250922171735-9219d122eba9 | ||
| google.golang.org/grpc v1.71.0 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check for patched gRPC versions and vulnerability details
echo "=== Checking gRPC vulnerability advisory ==="
gh api graphql -f query='
{
securityVulnerabilities(first: 5, ecosystem: GO, package: "google.golang.org/grpc") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'
echo ""
echo "=== Available gRPC versions from proxy ==="
curl -s "https://proxy.golang.org/google.golang.org/grpc/@v/list" | tail -10Repository: raystack/frontier
Length of output: 409
🌐 Web query:
GHSA-p77j-4mvh-x3m3 gRPC vulnerability
💡 Result:
GHSA-p77j-4mvh-x3m3 is a critical authorization bypass vulnerability (CVE-2026-33186) in gRPC-Go, the Go implementation of gRPC. Description: The gRPC-Go server improperly validates the HTTP/2 :path pseudo-header, accepting requests without a leading slash (e.g., "Service/Method" instead of "/Service/Method"). While routing works, authorization interceptors like grpc/authz evaluate the raw non-canonical path, bypassing "deny" rules for canonical paths if a fallback "allow" exists. Affected: gRPC-Go versions < 1.79.3, specifically servers using path-based authorization with deny rules and fallback allow. Impact: Attackers can send malformed HTTP/2 requests to bypass auth, gaining unauthorized access (CVSS 3.1: 9.1 Critical, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N). Fixed: Upgrade to 1.79.3 or later, which rejects invalid :path headers with codes.Unimplemented. Published: March 17-20, 2026. Official advisory: grpc/grpc-go GitHub security page.
Citations:
- 1: GHSA-p77j-4mvh-x3m3
- 2: https://nvd.nist.gov/vuln/detail/CVE-2026-33186
- 3: https://osv.dev/vulnerability/GHSA-p77j-4mvh-x3m3
- 4: GHSA-p77j-4mvh-x3m3
🌐 Web query:
google.golang.org/grpc v1.71.0 security vulnerability authorization bypass
💡 Result:
google.golang.org/grpc v1.71.0 is affected by CVE-2026-33186 (authorization bypass), because the advisory lists all versions < 1.79.3 as vulnerable. [1][2]
- What the bypass is: gRPC-Go accepted HTTP/2 requests whose
:pathomitted the required leading slash (e.g.,Service/Methodinstead of/Service/Method). The server could still route the call, but path-based authorization (includinggoogle.golang.org/grpc/authz) could evaluate the non-canonical path and fail to match “deny” rules written for canonical paths—allowing a bypass when a fallback “allow” exists. [1][2] - Who is impacted: gRPC-Go servers using path-based authorization (e.g.,
grpc/authz/ RBAC, or custom interceptors relying oninfo.FullMethod/grpc.Method(ctx)) with policies that include canonical-path denies but otherwise allow by default. [1][2] - Fix: upgrade to v1.79.3+ (patched). The fix rejects
:pathvalues that don’t start with/. [2] - Workaround (if you can’t upgrade immediately): add an outermost interceptor that rejects requests where
info.FullMethoddoesn’t start with/, and/or move to a “default deny” policy posture. [2]
Sources: GitHub Security Advisory GHSA-p77j-4mvh-x3m3 / CVE-2026-33186, and NVD entry for CVE-2026-33186. [1][2]
🌐 Web query:
gRPC Go v1.71.1 security patch release notes
💡 Result:
gRPC-Go v1.71.1 (released Apr 1) — “security patch” release notes
In the upstream grpc-go GitHub release entry for v1.71.1, there is no separate “Security” section; it’s published as a bug-fix release with the following items: (github.com)
- grpc: Fix extra read from the compressor when a compressed message is exactly at the limit (could panic with the built-in gzip compressor). (github.com)
- xds: Read bootstrap config before creating the first xDS client (instead of at package init time). (github.com)
- stats/opentelemetry: Use
TextMapPropagatorandTracerProviderfromTraceOptionsinstead of OpenTelemetry globals. (github.com) - client: Fix proxy-related races that could lead to deadlocks/panics. (github.com)
- client: Fix RPC failures (“no children to pick from”) when using a custom resolver that calls deprecated
NewAddress. (github.com) - wrr: Fix slow processing of address updates that could lead to issues including RPC failures with many backends. (github.com)
Source
- grpc/grpc-go GitHub releases page (v1.71.1 entry). (github.com)
Citations:
- 1: https://github.com/grpc/grpc-go/releases?page=3
- 2: https://github.com/grpc/grpc-go/releases?page=3
- 3: https://github.com/grpc/grpc-go/releases?page=3
- 4: https://github.com/grpc/grpc-go/releases?page=3
- 5: https://github.com/grpc/grpc-go/releases?page=3
- 6: https://github.com/grpc/grpc-go/releases?page=3
- 7: https://github.com/grpc/grpc-go/releases?page=3
- 8: https://github.com/grpc/grpc-go/releases?page=3
Upgrade google.golang.org/grpc to v1.79.3 or later to fix critical authorization bypass vulnerability.
gRPC-Go v1.71.0 is affected by CVE-2026-33186 (GHSA-p77j-4mvh-x3m3), a critical authorization bypass vulnerability (CVSS 9.1). Servers using path-based authorization can be bypassed via malformed HTTP/2 requests with missing leading slash in the :path pseudo-header. The vulnerability is fixed in v1.79.3+; earlier patch versions in the v1.71.x line do not address this issue.
🧰 Tools
🪛 OSV Scanner (2.3.5)
[CRITICAL] 57-57: google.golang.org/grpc 1.71.0: Authorization bypass in gRPC-Go via missing leading slash in :path in google.golang.org/grpc
(GO-2026-4762)
[CRITICAL] 57-57: google.golang.org/grpc 1.71.0: gRPC-Go has an authorization bypass via missing leading slash in :path
ravisuhag
force-pushed
the
chore/update-proton-gen-code
branch
from
22d2368 to
d60f136
Compare
Update PROTON_COMMIT to latest main (0b6548e) which migrates from envoyproxy/protoc-gen-validate to buf/validate annotations. Replace codegen-based validation with connectrpc.com/validate interceptor that automatically validates all incoming requests at runtime using buf.validate annotations from proto descriptors via protovalidate-go. - Update PROTON_COMMIT and regenerate proto code - Remove validate-go codegen plugin from buf.gen.yaml - Delete stale .pb.validate.go files (77k lines) - Add connectrpc.com/validate interceptor to Connect server - Remove manual .Validate()/.ValidateAll() calls from handlers and CLI
ravisuhag
force-pushed
the
chore/update-proton-gen-code
branch
from
d60f136 to
bd459d8
Compare
Tests were calling handlers directly, bypassing the connect interceptor where validation now runs after migrating to runtime proto validation.
Pull Request Test Coverage Report for Build 23807368112Details
💛 - Coveralls |
ravisuhag
changed the title
| return err | ||
| } | ||
|
|
||
| err := reqBody.ValidateAll() |
There was a problem hiding this comment.
since we are removing this, we should add a client side interceptor to replace this
There was a problem hiding this comment.
Since CLI is not throughput heavy and mostly for operations, I think it will be ok to just keep it at server level. Hence removed it completely.,
| sessionInterceptor, | ||
| authNInterceptor, | ||
| authZInterceptor, | ||
| validateInterceptor, |
There was a problem hiding this comment.
Let's move this before authZInterceptor. We use the request payload in that. It will be better to validate the payload.
There was a problem hiding this comment.
@rsbh you mean after authN and before authZ. ?
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (3)
go.mod (2)
57-57:⚠️ Potential issue | 🔴 CriticalUpgrade
google.golang.org/grpcfrom vulnerablev1.71.0.Line 57 is on a version affected by GHSA-p77j-4mvh-x3m3 / GO-2026-4762 (authorization bypass). Please bump to a patched release (
>= v1.79.3).Suggested diff
- google.golang.org/grpc v1.71.0 + google.golang.org/grpc v1.79.3
50-50:⚠️ Potential issue | 🟠 MajorBump OpenTelemetry SDK off vulnerable
v1.37.0.Line 50 keeps
go.opentelemetry.io/otel/sdk/metric v1.37.0, which is flagged for GHSA-9h8m-3fm2-qjrq / GO-2026-4394. Please upgrade to a patched version (>= v1.40.0) and keep OTEL module versions aligned.Suggested diff
- go.opentelemetry.io/otel/sdk/metric v1.37.0 + go.opentelemetry.io/otel/sdk/metric v1.40.0pkg/server/server.go (1)
157-165:⚠️ Potential issue | 🟠 MajorRun validation before authorization in interceptor chain.
validateInterceptoris currently afterauthZInterceptor(Line 163 → Line 164). If authZ depends on request fields, invalid payload reaches authZ first. Move validation before authZ (typically right after authN/session context setup).Suggested diff
interceptors := connect.WithInterceptors( otelInterceptor, connectinterceptors.UnaryConnectLoggerInterceptor(zapLogger.Desugar(), loggerOpts), connectinterceptors.UnaryConnectErrorResponseInterceptor(), sessionInterceptor, authNInterceptor, - authZInterceptor, validateInterceptor, + authZInterceptor, auditInterceptor, sessionInterceptor.UnaryConnectResponseInterceptor())
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: fcb82b55-58ca-45ec-972b-99f9e1bff530
⛔ Files ignored due to path filters (7)
go.sumis excluded by!**/*.sumproto/v1beta1/admin.pb.gois excluded by!**/*.pb.go,!proto/**proto/v1beta1/admin.pb.validate.gois excluded by!proto/**proto/v1beta1/frontier.pb.gois excluded by!**/*.pb.go,!proto/**proto/v1beta1/frontier.pb.validate.gois excluded by!proto/**proto/v1beta1/models.pb.gois excluded by!**/*.pb.go,!proto/**proto/v1beta1/models.pb.validate.gois excluded by!proto/**
📒 Files selected for processing (18)
Makefilebuf.gen.yamlcmd/group.gocmd/organization.gocmd/permission.gocmd/policy.gocmd/project.gocmd/role.gocmd/user.gogo.modinternal/api/v1beta1connect/audit_record.gointernal/api/v1beta1connect/audit_record_test.gointernal/api/v1beta1connect/organization.gointernal/api/v1beta1connect/organization_pats.gointernal/api/v1beta1connect/organization_test.gointernal/api/v1beta1connect/session.gointernal/api/v1beta1connect/user_pat.gopkg/server/server.go
💤 Files with no reviewable changes (14)
- cmd/group.go
- cmd/organization.go
- cmd/policy.go
- cmd/role.go
- cmd/project.go
- cmd/permission.go
- internal/api/v1beta1connect/organization.go
- cmd/user.go
- internal/api/v1beta1connect/audit_record.go
- internal/api/v1beta1connect/user_pat.go
- internal/api/v1beta1connect/audit_record_test.go
- internal/api/v1beta1connect/organization_test.go
- internal/api/v1beta1connect/session.go
- internal/api/v1beta1connect/organization_pats.go
✅ Files skipped from review due to trivial changes (1)
- buf.gen.yaml
🚧 Files skipped from review as they are similar to previous changes (1)
- Makefile
| validateInterceptor := validate.NewInterceptor() | ||
|
|
||
| interceptors := connect.WithInterceptors( | ||
| otelInterceptor, | ||
| connectinterceptors.UnaryConnectLoggerInterceptor(zapLogger.Desugar(), loggerOpts), | ||
| connectinterceptors.UnaryConnectErrorResponseInterceptor(), | ||
| sessionInterceptor, | ||
| authNInterceptor, | ||
| authZInterceptor, | ||
| validateInterceptor, | ||
| auditInterceptor, |
There was a problem hiding this comment.
Add tests for runtime validation interception path.
These changed lines are currently uncovered. Please add a server/integration test that asserts invalid annotated requests fail at the interceptor layer (and that authZ/audit are not reached for those requests).
4 participants
Summary
Update proton to latest main (
0b6548e) and migrate proto validation from codegen to runtime.Background
Proton moved validation annotations from
envoyproxy/protoc-gen-validatetobuf/validate. The oldvalidate-gocodegen plugin does not understandbuf.validateannotations — it silently generates emptyValidate()methods, making all rules no-ops.On main today, only 13 out of 253 handlers call
.Validate(). The remaining 133 annotated request types were never validated at the handler level. Some of these were caught deeper in the stack by service or repository layers, but not all:org_idreturnsErrInvalidID, invalid UUID fails on resource fetch. Works, but errors are less specific.CreateOrganization,CreateBillingAccountand similar handlers withbody: message.requiredcrash if body is nil instead of returning a validation error.CreateOrganizationInvitationwith emptyuser_idsreturns an empty response instead of rejecting (min_items=1).CheckResourcePermissionwithinvalid@#$%hits the DB and returns 404 instead of 400.What changed
PROTON_COMMITto0b6548evalidate-gocodegen plugin, update managed mode forbuf/validate.pb.gofiles, delete 77k lines of.pb.validate.gocodegen stubsconnectrpc.com/validate.NewInterceptor()to the Connect interceptor chain.Validate()calls (interceptor handles this now).ValidateAll()calls (server validates on receipt)connectrpc.com/validate; upgradeconnectrpc.com/connect,google.golang.org/protobufThe interceptor validates all incoming requests against
buf.validateannotations at runtime before any handler code runs. No per-handler code needed.Before vs after
.Validate()callsTest plan
go build ./...go vet ./...CodeInvalidArgument