Interesting. The CI failures do not seem to be caused by my changes, but how else would they have sneaked in? And yet at first glance I'm not seeing the erroring source, and even the Unchanged files with check annotations (Beta) section of the Files changed pane does not show the quoted error source matching the error in the message. (I'm attaching a screenshot)

Yes, the big difference is that these RPCs use Any fields in their responses. For the purpose of the checks that motivate this PR, we're not strictly checking that they occur in RPC error responses, but merely that they occur in fields with paths ending in .error.detailsand that the GAPICs in various languages can respond to such fields appropriately (motivating PR: googleapis/disco-to-proto3-converter#102).

As to changing existing RPCs to use the Any fields instead of adding new RPCs:
For erroring reponses:
For rest transport, at least, erroring RPCs go through ErrorResponse, which uses googleapi.Error, which in turn includes an ErrorItem that does not use Any fields. For grpc transport, I admit I'm not 100% clear on how the error from the server gets translated into a full error type message for the client to consume. Regardless, I'm reluctant to muck around with the existing error responses without a bigger discussion, which we may well need to have soon for the general Showcase testing infrastructure.

Extending the current Echo RPC:
IIUC your suggestion correctly, you're suggesting I fold the functionality currently in this PR into the existing Echo RPC: adding fields in the request to signal populating a singular or repeated error details (without marking the RPC as erroring via EchoRequest.error), and then changing the response to include those singular or repeated error details. I could certainly do that, though I shied away from it because I did not want to cause confusion by having these error details fields (currently only used for testing Any field decoding) separate from the RPC error setter EchoRequest.error and the gRPC error response. I thought (and still feel, TBH) that having this new functionality in separate RPCs is cleaner and more comprehensible for now.

Another option is that I could combine the two RPCs currently in the PR into a single RPC, where the request has two fields to signal a single error detail or multiple, and the response changes accordingly. That might be slightly simpler, though it would involve an additional level of nesting in the response since we want the path to both singular and repeated details to end with .error.details.

WDYT?

these RPCs use Any fields in their responses....checking...that they occur in fields with paths ending in .error.detailsand that the GAPICs in various languages can respond to such fields appropriately

Sorry, this is throwing me. So REGAPIC is supposed to only allow Any when used in the google.rpc.Status.details field? That seems not right? I think I'm confusing wanting to test Any parsing and something specific to error details.

which in turn includes an ErrorItem that does not use Any fields.

It should be using the Details field, and from what I can see, REGAPIC isn't reporting Details via the helper. I understand not wanting to rock the existing implementation's boat necessarily, but I think the well-worn path here is that the Details field contains the Any messages we want.

I understand wanting to add bespoke RPCs to not overload the existing one, and we definitely split Expand from PagedExpand for similar reasons (one is streaming, the other is paginated, but they are super similar).

I'm just not sure what is actually being tested here. If it is just that REGAPICs can handle an Any for a well known type (e.g. those in google/rpc/error_details.proto), then let's refactor the schema to reflect that general "well known type" case e.g. EchoAny and identify the well known types we'd support parsing here (for now it is just those under google/rpc/error_details.proto, but tomorrow it could be custom registered one via some generator config). This gives an Any specific test, a place to add onto which simplifies adding new tests, and flexibility for the future. Separate RPCs could be fine as well, but we already have a practice of putting > 1 test case in a single RPC (i.e. oneof with content or error for Echo).

message EchoAnyRequest {
  string content = 1;
}

message EchoAnyResponse {
  // This wraps the content in an ErrorDetail
  google.protobuf.Any singular_any = 1;

  // This splits content on space and reports each word as an ErrorDetail
  repeated google.protobuf.Any repeated_any = 2;

  // Eventually say we add a custom Any type like ShowcaseError that is triggered via other config...
  // google.protobuf.Any custom_any = 3;
}

As a result of an out-of-band conversation with @noahdietz , I corrected/clarified the PR description to better describe the motivation for this PR. I will also work on combining the two new RPCs into one for simplicity.

Consolidated what were formerly two RPCs into a single one. Update PR title and description to match.

Still need to investigate the CI errors.