Open boranby opened 1 month ago
Thanks for filing this issue.
c.Topics
in your code when you say you "list the topics"? I couldn't find it in that snippet you listed above and I wonder if the first API call being made is actually Publish
Hi @hongalex , thanks for your quick response.
dc.Update
Hm, given that this issue occurs with other products like Firestore, this likely isn't an issue with our library specifically. I would recommend checking your VPN settings to narrow down the issue: is it an issue with gRPC specifically or do HTTP calls also timeout? Is it something to do with the VPN connection itself?
I'm seeing something similar.
Is this something that has always happened, or started happening v1.44.0?
For us the v1.44.0
is when it started happening.
I double-checked v1.43.0
and it works as expected.
However after upgrading to v1.44.0
messages seem to never land in Receive()
:
err := sub.Receive(ctx, func(ctx context.Context, message *pubsub.Message) {
// this callback is never called
}
Another interesting observation is:
exists, err := sub.Exists(ctx)
^ that returns true
in v1.43.0
and false
in v1.44.0
.
@ekartsev just to confirm, you're also encountering issues with a VPN enabled?
No, in my case the service is running in AWS.. I'm not sure about the actual network layout there, but it's probably a VPC with firewall, etc.
It doesn't explain why 1.43.0
works, though 🤷
Hm weird, our integration tests haven't caught anything that broke Receive
nor Exists
in 1.44.
Since it's not clear if the issue is with a firewall, and you're not explicitly seeing deadline exceeded, can you create a new issue for your problem?
On that issue, could you also include:
I had a similar issue with another library. In my case, it was caused by internaloption.EnableNewAuthLibrary()
being added to the default GRPC options. Setting the ENV GOOGLE_API_GO_EXPERIMENTAL_DISABLE_NEW_AUTH_LIB
to true
fixed it.
@zachbadgett do you have a minimal reproducer? In your case is there any special networking?
I had a similar issue with another library. In my case, it was caused by
internaloption.EnableNewAuthLibrary()
being added to the default GRPC options. Setting the ENVGOOGLE_API_GO_EXPERIMENTAL_DISABLE_NEW_AUTH_LIB
totrue
fixed it.
Adding this ENV variable to our service fixed the issue as well. Maybe we are missing some transitive dependency that makes this work, but for us 1.44+ doesn't work without adding this ENV variable.
@codyoss yes, there's egress restrictions. I figured it's most likely caused by a new url being hit that is not allowed yet, just haven't spent the time to figure it out.
@zachbadgett If you do find out, please share!
I encountered this same issue with the cloud.google.com/go/kms/apiv1
KeyManagementClient. Setting GOOGLE_API_GO_EXPERIMENTAL_DISABLE_NEW_AUTH_LIB=true
also resolved the issue.
For those using Pub/Sub, can you try upgrading to the latest version 1.45.1 and see if the issue still remains?
Client
PubSub
Environment
Redhat Enterprise Linux (no container)
Code and Dependencies
go.mod
```text module modname go 1.23.0 require ( cloud.google.com/go/pubsub v1.44.0 google.golang.org/protobuf v1.35.1 ) ```Expected behavior
It shouldn't matter for Pub/Sub client that the computer it runs has an open VPN connection. It should publish without any issues.
Actual behavior
If I enable VPN to access a private network from the machine, Pub/Sub publish returns
context deadline exceeded
error. When I close the VPN, it publishes and get the id of the publish. It can generate the client, get the Topic, list the topics. However, it stucks at theresult.Get(ctx)
.