Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent subscription behavior with deleted topic #2413

Closed
joeholley opened this issue Sep 23, 2016 · 3 comments
Closed

Inconsistent subscription behavior with deleted topic #2413

joeholley opened this issue Sep 23, 2016 · 3 comments
Assignees
Labels
api: pubsub Issues related to the Pub/Sub API. backend priority: p2 Moderately-important priority. Fix may not be included in next release.

Comments

@joeholley
Copy link

What were you trying to do?

Note: Before beginning, the topic 'test_topic' and the subscription 'test_sub' don't exist in the project.

via google.cloud python pubsub module:

  1. Create 'test_topic' Cloud PubSub topic if it doesn't exist
  2. Create 'test_sub' pull subscription to that topic if it doesn't exist
  3. Attempt to pull messages from the 'test_sub' subscription
  4. Delete the 'test_topic'. NOTE: We are not deleting 'test_sub', it should be given a topic name of 'deleted-topic' as per https://cloud.google.com/pubsub/publisher#delete)
  5. repeat # 1-4

What did you expect to happen?

On the second run:

What actually happened?

After having created the topic and subscription once, then having deleted/recreated the topic, the subscription shows up in 'subscriptions to topics not in this project' under pantheon (i.e. has a topic name of 'deleted-topic' as per https://cloud.google.com/pubsub/publisher#delete) as expected. But the behavior is inconsistent when accessing it programmatically via the google.cloud python module:

  1. Listing the subscriptions for the topic gives you an list that doesn't include the subscription in question. pubsub.Client().topics.list_topics() returns a list without the 'test_sub' subscription in it
  2. BUT... Checking if the sub exists with pubsub.Client().topic('test_topic').subscription('test_sub').exists() returns... True
  3. And, it can be pulled from via pubsub.Client().topic('test_topic').subscription('test_sub').pull()
@dhermes dhermes added the api: pubsub Issues related to the Pub/Sub API. label Sep 23, 2016
@tseaver
Copy link
Contributor

tseaver commented Sep 24, 2016

Listing the subscriptions for the topic gives you an list that doesn't include the subscription in question. pubsub.Client().topics.list_topics() returns a list without the 'test_sub' subscription in it

Right, the subscription (at path /projects/<your-project-id>/subscriptions/test-sub) still exists, but is not bound to the topic (at path /projects/<your-project-id>/topics/test-topic).

BUT... Checking if the sub exists with pubsub.Client().topic('test_topic').subscription('test_sub').exists() returns... True

As it should: your example doesn't delete the orphaned subscription created during the first time through. Creating it anew from the topic doesn't change its path, which is still /projects/<your-project-id>/subscriptions/test-sub. However, the newly-created subscription instance does have a topic assigned (the one it was just created from).

And, it can be pulled from via pubsub.Client().topic('test_topic').subscription('test_sub').pull()

This one is the slightly odd case: it would almost appear that the path used in Subscription.pull is not based on the subscription's own path, but on that of its topic: however, the subscription's own path is used. I would speculate that the back-end is actually satisfying the pull request based on the newly re-created topic, even though it does not return that topic's path when reloading the subscription.

@joeholley
Copy link
Author

I understand all the of the mechanics of why this back-end causes the python library to return these results, but users of the python library should not have to understand these back-end implementation details IMO. If the plan is to keep this mapping, perhaps additional effort (i.e. special-case code) should be applied to making the python object behaviors consistent with reasonable user expectations? At least with respect to very basic patterns like "I'll ask for the list of all subscriptions to this topic, and if the sub I want to create isn't in the list, I'll create it.", which doesn't work as intended in this case (the creation attempt fails)?

@lukesneeringer lukesneeringer added the priority: p2 Moderately-important priority. Fix may not be included in next release. label Apr 19, 2017
@lukesneeringer
Copy link
Contributor

Hello! :-)
First, a mea culpa; I have not done as good of a job at keeping up with issues as I should have. If you are getting this (I admit it) cut and paste, it is likely because your issue sat for too long.

In this case, I have been in the process of making a radical update to the PubSub library (#3637) to add significant performance improvements and a new surface, which we hope to launch soon. As such, I am clearing out issues on the old library. It is my sincere goal to do a better job of being on top of issues in the future.

As the preceding paragraph implies, I am closing this issue. If the revamped library does not solve your issue, however, please feel free to reopen.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: pubsub Issues related to the Pub/Sub API. backend priority: p2 Moderately-important priority. Fix may not be included in next release.
Projects
None yet
Development

No branches or pull requests

4 participants