refactor(proto): introduce shared ServiceError type and begin unifying error patterns#823
Open
NewCoder3294 wants to merge 2 commits intokoala73:mainfrom
Open
refactor(proto): introduce shared ServiceError type and begin unifying error patterns#823NewCoder3294 wants to merge 2 commits intokoala73:mainfrom
NewCoder3294 wants to merge 2 commits intokoala73:mainfrom
Conversation
…g error patterns Create a shared ServiceError message in core/v1 with machine-readable code + human-readable message fields. Migrate three response messages from ad-hoc `string error` to the new type as a first step toward full unification (ref koala73#191): - GetTemporalBaselineResponse (infrastructure) - RecordBaselineSnapshotResponse (infrastructure) - SearchGdeltDocumentsResponse (intelligence) Old field numbers are reserved to maintain wire compatibility. Handler code and client-side consumers updated to use the new serviceError field with structured { code, message } objects. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The sebuf v0.7.0 codegen dropped @ts-nocheck from generated files, causing pre-existing type errors to surface. Restore the directive on the four files changed by this PR, and restore all other generated files to their original state since they had no proto changes. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
@NewCoder3294 is attempting to deploy a commit to the Elie Team on Vercel. A member of the Team first needs to authorize it. |
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.
Summary
Closes #191 (first step).
The codebase currently has four different error patterns coexisting across proto response messages:
string error-- a plain string field (e.g.GetTemporalBaselineResponse,SearchGdeltDocumentsResponse,GetUSNIFleetReportResponse)bool success+string error-- a success flag paired with an error string (e.g.ListTechEventsResponse,GetPopulationExposureResponse)GeneralError-- a structured oneof for infrastructure-level errors like rate limiting, geo blocking, upstream outages (core/v1/general_error.proto, currently unused in any response message){ error: string }/{ message: string }returned directly by the gateway error boundary and error-mapperThis PR introduces a shared
ServiceErrormessage type as the standard pattern for per-RPC business logic errors and migrates three response messages as a proof of concept:proto/worldmonitor/core/v1/service_error.protowithcode(machine-readable) +message(human-readable) fieldsGetTemporalBaselineResponse,RecordBaselineSnapshotResponse,SearchGdeltDocumentsResponsestring errorfield numbers are reserved to maintain wire compatibility{ code, message }objects (e.g.INVALID_ARGUMENT,INTERNAL,UPSTREAM_ERROR)gdelt-intel.ts) updated to useresp.serviceErrorMigration approach
The field is named
service_error(noterror) to avoid conflict with the reserved old field name. Future PRs will migrate the remaining response messages following this same pattern. TheGeneralErrortype remains available for infrastructure-level cross-cutting concerns (rate limiting, geo blocking, etc.).Changed files
proto/worldmonitor/core/v1/service_error.protoproto/.../get_temporal_baseline.protostring errorwithServiceError service_errorproto/.../record_baseline_snapshot.protostring errorwithServiceError service_errorproto/.../search_gdelt_documents.protostring errorwithServiceError service_errorserver/.../get-temporal-baseline.tsserviceError: { code, message }server/.../record-baseline-snapshot.tsserviceError: { code, message }server/.../search-gdelt-documents.tsserviceError: { code, message }src/services/gdelt-intel.tsresp.errortoresp.serviceErrorsrc/generated/...docs/api/...Test plan
tsc --noEmitpasses (non-generated code has zero errors)buf lintpasses for all modified proto filesserviceErrorobject on failureserviceErroron invalid paramsserviceErroron empty updates🤖 Generated with Claude Code