feat(api): add bounded gRPC operational adapter - #12
Merged
Conversation
6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Linked Issue
Fixes #11
Summary
grpc.health.v1.HealthserviceNOT_SERVINGbefore drainRequired Format
feat/,fix/,docs/,test/,refactor/,perf/,security/,chore/,ci/,build/,release/, orrevert/.fix(consensus): reject equivocated proposer slots.Scope And Project Status
No performance claim is introduced.
Protocol, Safety, And Compatibility
Apply.The unchecked boundary is intentional: this PR introduces the local operational gRPC transport and its resource accounting. It is isolated from consensus and persistence, registers only the standard gRPC Health schema, and opens no listener. Message sizes, application metadata, transport headers, concurrent streams, their per-connection products, connection age/idle, keepalive, unary work, request IDs, and shutdown are bounded and validated without silent clamping. A future composition root must separately bound process-wide listener connections when it wires an active transport. There are no releases or runtime users, so no migration or compatibility layer is required. Rollback is a clean revert of this adapter and the grpc-go dependency.
Validation
git diff --checkpython3 scripts/check_docs.pygo mod verifyand a cleango mod tidydiffgo vet ./...go test -count=1 -mod=readonly ./...go test -race -count=1 -mod=readonly ./...python3 scripts/check_go_architecture.pyAdditional focused validation:
go test -count=20 ./pkg/api/grpcservergo test -race -count=20 ./pkg/api/grpcserver-race -count=100amd64andarm64static builds with-trimpathProtocol property, vector, model, Byzantine, partition, crash-recovery, snapshot, and chaos suites are not applicable because this PR adds no consensus, storage, canonical encoding, custom wire schema, or active runtime. Residual operational risk is limited to future listener/TLS/composition-root integration, which remains explicitly absent and must receive its own issue and tests.
Risk And Rollback
The main risks are transport lifecycle races, inaccurate resource ceilings, readiness becoming SERVING too early, and sensitive metadata entering logs. The implementation starts
NOT_SERVING, uses the existing atomic tracker, freezes a single-use lifecycle, makes concurrent shutdown callers share the initiating drain result, forces Stop on deadline, counts repeated HTTP/2 metadata fields, and logs only fixed allowlisted fields. Unit, integration, stress, and race tests cover these boundaries.Rollback by reverting this commit. No persisted data, protocol state, generated code, migration, listener, or compatibility shim must be removed.