does anyone have any tips on someone who doesn't l...
# help
does anyone have any tips on someone who doesn't live in the java world might go about debugging why I can't serialize a message that I got in response to querying the actual server using grpcurl? Can I get the server to dump a readable version of the dsc?
Copy code
Exception in thread "grpc-default-executor-0" Cannot find field: matchId in message genius_sports_replica.v1alpha.Match
 	at org.wiremock.grpc.internal.JsonMessageUtils.lambda$toMessage$1(
 	at com.github.tomakehurst.wiremock.common.Exceptions.uncheck(
 	at org.wiremock.grpc.internal.JsonMessageUtils.toMessage(
 	at org.wiremock.grpc.internal.UnaryServerCallHandler.lambda$invoke$0(
 	at com.github.tomakehurst.wiremock.http.AbstractRequestHandler.handle(
 	at org.wiremock.grpc.internal.UnaryServerCallHandler.invoke(
 	at org.wiremock.grpc.internal.UnaryServerCallHandler.invoke(
 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
 	at java.base/java.util.concurrent.ThreadPoolExecutor$ Source)
 	at java.base/ Source)
testing with the demo app, It's fine if I name fields foo_bar or fooBar (except in $. syntax where it really wants fooBar (field is defined in proto as foo_bar)
The dsc is compiled directly from the .proto so you should be able to use that to inspect the structure
If you want to look at the JSON WireMock is seeing you can enable
at startup
So, I've downloaded grpcui which can take a protoset (dsc) file and make requests like grpcurl but from a web ui. I loaded the protoset I'm loading into wiremock, I sent the request and I get back a response, no errors. This means it has correctly parsed the response message. The response data is json and matches the underscore version of the JSON. it reports no problems. When I try to make the same request, using this returned json as the body of the mapping response, I get an error that it cannot find the first field of the repeated message which causes a stack trace to be dumped by wiremock. I'm using v0.2 which we setup to work yesterday and I've confirmed that the naive example still works in wiremock.
I have just noticed, however:
Copy code
WARNING: The descriptor for message type ".genius_sports_replica.v1alpha.Match" cannot be found and a placeholder is created for it
note the leading dot... is that a root namespace anchor like it would be in dns?
is it failing to match .genius_sports_replica and genius_sports_replica?
Copy code
package genius_sports_replica.v1alpha;

import "genius_sports_replica/v1alpha/competitor.proto";
import "genius_sports_replica/v1alpha/venue.proto";
import "google/protobuf/duration.proto";
import "google/protobuf/timestamp.proto";

message Match {
  int32 match_id = 1;

protoc --include_imports --descriptor_set_out mock/wiremock/genius/grpc/api.dsc -I ../../genius-sports-replica/api/proto -I ../../googleapis -I ../../grpc-gateway $file
genius-sports-replica/api/proto contains genius_sports_replica/v1alpha/match.proto (and friends) What's adding the leading dot here?
actually I'm seeing .genius_sport_replica all over the generated dsc
so the difference is, I did not create the proto from the directory containing the api. If I do, the file generated is different
OK, I merged all the .proto for that module into a single file
and now the only warnings I'm getting are about the google imports
so, I think you have a problem parsing the imports.
BOOM, with that change, I was able to return mock data.
and able to test it...
SERIOUSLY, thanks so much for this software
if we can get to the bottom of the dsc parsing problem (trim leading dots?) we'll be good I think
I was able to resolve the issues I was having using wiremock grpc extension by merging all the files for my module into a single file (avoiding imports for all except google)... obviously this isn't something everyone will reasonably be able to do, so I hope you can fix the imported objects - looks like maybe the leading dot is the issue and either adding to all, or removing from all might well solve the problem.
Please could you share a project that replicates the issue you’ve described? Agree it would be good to get to the bottom of this, even if it’s just to add a warning in the docs.
OK, confirmed this is an issue, fix in progress:
🙌 1
Confirmed, I've rebuilt my docker containers with this new standalone jar 0.3.0 and it's working in my test with the original dsc
Thanks for confirming!