Support json names in field mask generation

[william-plano-oxb]

Added tests for using jsonpb with OrigName: false
Added benchmarks for FieldMaskFromRequestBody called with a message descriptor

[william-plano-oxb]

Thankfully this doesn't look like it's significantly slower than before:

BenchmarkABEFieldMaskFromRequestBodyWithDescriptor-12            	    3000	    373950 ns/op
BenchmarkNonStandardFieldMaskFromRequestBodyWithDescriptor-12    	  100000	     20738 ns/op

vs

BenchmarkABEFieldMaskFromRequestBody-12            	    5000	    337770 ns/op
BenchmarkNonStandardFieldMaskFromRequestBody-12    	  100000	     18189 ns/op

[johanbrandhorst]

I don't understand the bazel error well enough to say if it's real: https://circleci.com/gh/grpc-ecosystem/grpc-gateway/4473?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link @drigz @achew22 please bazel police come to my aid.

[johanbrandhorst]

This includes a change to the runtime package, so we will likely have to release a new minor version immediately after merge to stem the flow of people raising issues that are rooted in installing the gateway the wrong way.

[william-plano-oxb]

This includes a change to the runtime package, so we will likely have to release a new minor version immediately after merge to stem the flow of people raising issues that are rooted in installing the gateway the wrong way.

I'm not sure that I follow, but in any case a new release sounds good to me 😄

[johanbrandhorst]

I'm not sure that I follow, but in any case a new release sounds good to me smile

To give you an idea: #963, #1023

[william-plano-oxb]

To give you an idea: #963, #1023

Aah okay, I understand
quickly checks his Dockerfile
I think I'm good 😁

[william-plano-oxb]

I don't understand the bazel error well enough to say if it's real: https://circleci.com/gh/grpc-ecosystem/grpc-gateway/4473?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link @drigz @achew22 please bazel police come to my aid.

Are you able to poke it to re-run the workflow?

[johanbrandhorst]

Are you able to poke it to re-run the workflow?

Yes

[johanbrandhorst]

Are you able to poke it to re-run the workflow?

Yes

:(

[johanbrandhorst]

fatal error: error in backend: IO failure on output stream: Cannot allocate memory

This is surely a random error. I'll poke it again.

[william-plano-oxb]

Are you able to poke it to re-run the workflow?

Yes

:(

Hrm, that seems worse ☹️

[william-plano-oxb]

fatal error: error in backend: IO failure on output stream: Cannot allocate memory

This is surely a random error. I'll poke it again.

I do have some pretty long names in the tests here, they run fine locally, but maybe that's the issue?

[johanbrandhorst]

fatal error: error in backend: IO failure on output stream: Cannot allocate memory

This is surely a random error. I'll poke it again.

I do have some pretty long names in the tests here, they run fine locally, but maybe that's the issue?

Nah we get the occasional Bazel error, we're working on it: #968.

[william-plano-oxb]

Okay, I ran bazel test //... locally and got some errors along the lines of:

compilepkg: missing strict dependencies:
	/private/var/tmp/_bazel_william.plano/907f576adbee9625b7b379068b79de6e/sandbox/darwin-sandbox/487/execroot/grpc_ecosystem_grpc_gateway/bazel-out/darwin-fastbuild/bin/examples/proto/examplepb/darwin_amd64_stripped/examplepb_go_proto%/github.com/grpc-ecosystem/grpc-gateway/examples/proto/examplepb/a_bit_of_everything.pb.gw.go: import of "github.com/golang/protobuf/descriptor"

This seems likely to be legitimate since I've added descriptor as a new dependency to the generated gw files. I'll try and work out what I need to put where to get it to work.

[drigz]

This seems likely to be legitimate since I've added descriptor as a new dependency to the generated gw files. I'll try and work out what I need to put where to get it to work.

Looks like you need to manually add it as a dep for the :examplepb_go_proto target. I don't know enough about Gazelle to know if this should have been done automatically, but you could try filing an issue.

patch -p1 << EOF
diff --git a/examples/proto/examplepb/BUILD.bazel b/examples/proto/examplepb/BUILD.bazel
index c652f7b..9e4011c 100644
--- a/examples/proto/examplepb/BUILD.bazel
+++ b/examples/proto/examplepb/BUILD.bazel
@@ -51,6 +51,7 @@ go_proto_library(
         "//examples/proto/sub:go_default_library",
         "//examples/proto/sub2:go_default_library",
         "//protoc-gen-swagger/options:go_default_library",
+        "@com_github_golang_protobuf//descriptor:go_default_library_gen",
         "@go_googleapis//google/api:annotations_go_proto",
     ],
 )
EOF

[william-plano-oxb]

Thanks @drigz, that did the trick. I had to add a # keep comment to convince bazel not to throw it away, luckily there was a similar comment a few lines above to set precedent. I don't think I understand enough about what's going on here to form a coherent issue report.

[william-plano-oxb]

Aargh, "it worked on my machine":tm:
I think we're maybe back to the random error again:

fatal error: error in backend: IO failure on output stream: Cannot allocate memory

[johanbrandhorst]

🔨

[johanbrandhorst]

Thanks for your contribution!