Skip to content

Propagate more WCI client error types to callers - #12180

Open
johanngan wants to merge 1 commit into
mainfrom
johanngan/wci-errors
Open

johanngan wants to merge 1 commit into
mainfrom
johanngan/wci-errors

Conversation

@johanngan

@johanngan johanngan commented Sep 18, 2026

Copy link
Copy Markdown

What changed?

There are more error types from the Worker Controller Instance client (for serverless worker configuration) that would probably be good to expose to users as ApplicationErrors than just InvalidArgument without needing to explicitly configure frontend.maskInternalErrorDetails to false. Start by adding the FailedPrecondition code. The conversion logic is moved to a common function, so this can be extended easily as needed.

Why?

Currently only the InvalidArgument gRPC code gets propagated from WCI client calls without getting wrapped in an Internal error by the calling code. This means that any other error types returned by the WCI client will by default get masked by the frontend to the generic internal error message, "something went wrong, please retry", which isn't particularly helpful. This happens even if the WCI client itself returns a more useful error message that isn't of type InvalidArgument.

How did you test it?

  • built
  • run locally and tested manually
  • covered by existing tests
  • added new unit test(s)
  • added new functional test(s)

@johanngan
johanngan requested a review from 02strich September 18, 2026 22:37
@johanngan
johanngan requested a review from a team as a code owner September 18, 2026 22:37
@CLAassistant

CLAassistant commented Sep 18, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

Currently only the InvalidArgument gRPC code gets propagated without
getting wrapped in an Internal error by the calling code. This means
that any other error types returned by the WCI client will by default
get masked by the frontend to the generic internal error message,
"something went wrong, please retry".

There are more error types that would probably be good to expose to
users as ApplicationErrors without needing to explicitly configure
frontend.maskInternalErrorDetails to false. Start by adding the
FailedPrecondition code. The conversion logic is moved to a common
function, so this can be extended easily as needed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants