Client
cloud functions
Environment
N/A
Code
package something
import (
"fmt"
"cloud.google.com/go/functions/metadata"
)
func Something(ctx context.Context, m PubSubMessage) error {
fmt.Println("%+v\n", ctx)
md, err := metadata.FromContext(ctx)
if err != nil {
return nil, fmt.Errorf("problem reading metadata from context: %w", err)
}
return nil
}
Expected behavior
Metadata should be extracted from context
Actual behavior
Logs show the following:
D Something e5ue70qrshow 2020-04-23 14:05:00.221 Function execution started
D Something e5ue70qrshow 2020-04-23 14:05:00.330 context.Background.WithValue(type *http.contextKey, val <not Stringer>).WithValue(type *http.contextKey, val 169.254.8.130:8080).WithCancel.WithCancel.WithValue(type metadata.contextKey, val <not Stringer>)
D Something e5ue70qrshow 2020-04-23 14:05:00.331 Function execution took 111 ms, finished with status: 'error'
Something e5ue70qrshow 2020-04-23 14:05:01.412 Function error: problem reading metadata from context: unable to find metadata
Screenshots
N/A
Additional context
Using v0.56.0 with a vendor folder. If you remove the vendor folder it works fine, however, vendor folder is needed for private dependencies.
This sounds like more of an issue with cloud functions and not the metadata client, but I will poke around quick to make sure. If so though, the right place to file with bug would this link
cc @juliehockett
@dbarrosop I did look into this a bit and I do believe this issue is actually apart of cloud functions. Would you mind opening a bug with this link: https://issuetracker.google.com/issues/new?component=187195&template=0.
will do, thanks!
Hey there @codyoss having the same issue here. Are there any thoughts about it? How is it going?
https://github.com/GoogleCloudPlatform/buildpacks/commit/6879fdb359be84f888b6e0f2fc9506426dff4651 should fix this, but it didn't make the cutoff for the last release. It should be available on Cloud Functions in the next week or two.
GoogleCloudPlatform/buildpacks@6879fdb should fix this, but it didn't make the cutoff for the last release. It should be available on Cloud Functions in the next week or two.
Thanks @juliehockett!!!
The commit has been rolled back https://github.com/GoogleCloudPlatform/buildpacks/commit/676a49b81a0756866b76014bf19e2f2442156b12
Will there be another fix or workaround?
We discovered that this change introduces a number of very thorny common cases that result in build failures.
A workaround is to vendor your code and then remove this specific package from that folder (rm -f vendor/cloud.google.com/go/functions/metadata prior to deploying to Cloud Functions. We recognize that this really isn't ideal, but the hard failures with no workaround that we see otherwise in common builds make the alternative implausible.
We're hoping to bring a newer version of Go to Cloud Functions soon, and provide the more native vendoring support that appears in 1.14+. From https://golang.org/ref/mod#build-commands:
By default, if the go version in go.mod is 1.14 or higher and a vendor directory is present, the go command will act as if -mod=vendor were used. Otherwise, the go command will act as if -mod=mod were used.
In other words, eventually, the workaround will be to deploy to a later version of Go (in which we won't need to do the vendoring gymnastics the buildpacks code currently does), but Cloud Functions does not yet have that support and therefore the above workaround is necessary.
Thanks for the details. And rm -f vendor/cloud.google.com/go/functions/metadata works.
FYI, if you use the Serverless framework, you can exclude the vendor/cloud.google.com/go/functions/** in the serverless.yml to solve this problem.
@juliehockett sorry for nagging you but do you know if this is still an issue? According to the docs go 1.11 and 1.13 are the only runtimes supported but https://github.com/GoogleCloudPlatform/buildpacks/commit/f4197bb8db332918ade9ed3b2f1ac0f57abe12a9 points to 1.16, does that mean it is supported and the docs are outdated? If 1.16 is supported, does that mean that go.mod file + vendor folder are now supported?
Thanks!
Most helpful comment
We discovered that this change introduces a number of very thorny common cases that result in build failures.
A workaround is to vendor your code and then remove this specific package from that folder (
rm -f vendor/cloud.google.com/go/functions/metadataprior to deploying to Cloud Functions. We recognize that this really isn't ideal, but the hard failures with no workaround that we see otherwise in common builds make the alternative implausible.We're hoping to bring a newer version of Go to Cloud Functions soon, and provide the more native vendoring support that appears in 1.14+. From https://golang.org/ref/mod#build-commands:
In other words, eventually, the workaround will be to deploy to a later version of Go (in which we won't need to do the vendoring gymnastics the buildpacks code currently does), but Cloud Functions does not yet have that support and therefore the above workaround is necessary.