-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Add Pub/Sub snapshot and seek functionality #3303
Conversation
Notes: - cloud.google.com links do not yet work - SeekResponse exists but is empty, so corresponding methods return None instead - It's not documented whether the deleted topic path applies to snapshots analogous to how it applies to subscriptions, but it seems logical to assume so. - The new Subscription fields are part of this release but will come shortly as a separate PR. (They can be done independently of the snap-seek work.)
@lukesneeringer CI is failing because it thinks this branch doesn't have test coverage. There is a actually a test intended to exercise this branch. I checked that raising an exception in the allegedly uncovered lines of code causes the test to fail, so not sure exactly why codecov doesn't like this. |
This looks fine other than figuring out the CI failure. I can look at that first thing tomorrow morning. |
The reason you are not getting full coverage is because of the if time is not None:
data['time'] = time
elif snapshot is not None:
data['snapshot'] = snapshot You have a test for I am assuming that setting neither option is an error case. (I assume this is also true if you set both.) Your current logic basically makes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved, but make sure you agree with my changes.
Thanks for figuring this out, @lukesneeringer. That makes sense, and I agree with your changes. |
Add Pub/Sub snapshot and seek functionality
@geigerj, @lukesneeringer I'm curious: why did we rush in support for a feature which is not yet public (i.e., it requires whitelisting, has no public docs, etc., even a month later). |
Because it was pushed for by the Pub/Sub team. They claimed at the time that support was imminent. (I raised the non-public issue and was told we were making an exception in this case.) |
@lukesneeringer Seems like your concern was well-founded. I think our normal protocol (develop and review the client-side support in a private fork, push to public at launch) is more sensible. |
For features like this, I would prefer not develop them at all until they go public. :-) |
Notes:
None instead
snapshots analogous to how it applies to subscriptions, but it seems
logical to assume so.
shortly as a separate PR. (They can be done independently of the
snap-seek work.)