You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 07e26d5
Browse filesBrowse the repository at this point in the historyBrowse files
fix: place gRPC proto at core-standard path and make grpc boot import-safe (#14)
Addresses review findings on the optional gRPC server.
#1 (main.py): the grpc server was imported at module top level, so importing
src.main required the generated stubs. Runtime.Init runs GenerateOpenAPI, which
imports src.main *before* Sync generates those stubs (and they are git-ignored,
so a fresh clone has none) — Init failed with ModuleNotFoundError. The import
now lives inside the startup handler; OpenAPI generation never fires startup, so
the module imports cleanly without stubs.
#2 (proto location): the proto was scaffolded at code/proto/api.proto, but
core's LoadEndpoints re-derives the gRPC contract from standards.ProtoPath
(proto/api.proto at the service root) and the manifest stores no proto bytes.
The endpoint therefore reloaded with zero RPCs and dependent services could not
generate clients. The proto now lives at the service-root standard path (Buf and
grpcEndpoint read it there), and defaultProtoPath is bound to standards.ProtoPath
so it can never drift again.
#3 (server.py): add_insecure_port returns 0 instead of raising when a port can't
be bound, so the server would "start" listening on nothing while FastAPI stayed
healthy. It now raises, which also fails the pod's HTTP readiness probe via the
shared lifespan (covers the gRPC-readiness gap).
Tests: added a reload regression test asserting the gRPC endpoint keeps its RPCs
after LoadEndpoints (would have caught #2), and a check that src.rpc is never
imported at module top level (would have caught #1).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
0 commit comments