Skip to content

Conversation

@philicious
Copy link
Contributor

@philicious philicious commented Aug 18, 2025

The GCP GO SDK introduced a new v2 version of their PubSub library with the v1.50 release of the pubsub pkg. Deprecating the old interface and encouraging to upgrade within a 1yr grace period. See googleapis/google-cloud-go#12218 for reference

For downstream users (like me) being able to update to the new v2 library while also using the cloudevents SDK, its necessary to upgrade the pubsub protocol in the cloudevents SDK or we cannot pass in types to funcs like WithReceiveSettings anymore.

Sooo I took the chance and migrated the code to use pubsub/v2.
Noteworthy changes:

  • upstream dropped the Exists functions on Topic/Subscription and suggest optimistically using them and handling NotFound errors.
  • the CreateX funcs got moved to an admin plane
  • Topic and Subscription names now need to be fully-qualified names, including projectID
  • Topic and Subscription types got renamed to Publisher/Subscriber

(https://github.com/googleapis/google-cloud-go/blob/main/pubsub/MIGRATING.md)

PS: as a separate commit, I added a fix for the existing ReceiveSettings assertion that didnt actually test for the passed in ReceiveSettings anymore as the NumGoRoutines override was removed after these assertions were initially added

@philicious philicious requested a review from a team as a code owner August 18, 2025 17:27
@philicious philicious force-pushed the refactor-pubsubv2 branch 3 times, most recently from b93aca6 to d97e465 Compare August 18, 2025 22:53
@philicious philicious changed the title Refactor pubsub protocol to use new upstream v2 interface Refactor pubsub protocol to use new upstream v2 library Aug 18, 2025
@tyrone-anz
Copy link

Just here to say we have same issue. We are unable to upgrade to libraries using pubsub/v2 because the cloudevents SDK is not yet supporting it.

@embano1
Copy link
Member

embano1 commented Aug 24, 2025

Topic and Subscription names now need to be fully-qualified names, including projectID

Can you please update the public config parameters/related options to indicate this and reduce developer experience issues?

Topic and Subscription types got renamed to Publisher/Subscriber

Seems those are mainly used internally and not really breaking the public API (despite the upgrade to v2 obviously being considered a breaking change)?

@philicious
Copy link
Contributor Author

Topic and Subscription names now need to be fully-qualified names, including projectID

Can you please update the public config parameters/related options to indicate this and reduce developer experience issues?

imho there is no change in cloudevents public config by that change. It still requires a ProjectID and topic/subscription ID as formerly, which are then passed down to PubSub SDK. But now they get concat before being passed down and formerly PubSub SDK did that internally I assume.

Topic and Subscription types got renamed to Publisher/Subscriber

Seems those are mainly used internally and not really breaking the public API (despite the upgrade to v2 obviously being considered a breaking change)?

Correct: The new Publisher and Subscriber types loosely reference a Topic/Subscription and some funcs got moved from the latter to the new types. However those new handlers are not exposed to the cloudevents public interface

@embano1
Copy link
Member

embano1 commented Aug 30, 2025

imho there is no change in cloudevents public config by that change. It still requires a ProjectID and topic/subscription ID as formerly

But IMHO that contradicts your comment now need to be fully-qualified names, including projectID which seemed not to be the case before? If these strings now require a different (semantical) format, it should be documented in the option/API and would be considered breaking.

@philicious
Copy link
Contributor Author

philicious commented Aug 30, 2025

But IMHO that contradicts your comment now need to be fully-qualified names, including projectID which seemed not to be the case before? If these strings now require a different (semantical) format, it should be documented in the option/API and would be considered breaking.

I was referring to the changes required for the migration to PubSub v2 library: it now requires them to be fully-qualified but as the cloudevents user supplies both projectID and topicID/subID anyways, we can simply construct the FQDN by the same supplied options as before.
So no breaking code change.

Copy link
Member

@embano1 embano1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a nit, otherwise LGTM if CI passes and assuming you've verified this change in a real PubSub environment?

if st, ok := status.FromError(err); ok && st.Code() == codes.NotFound {
return false, nil // Topic does not exist.
}
return false, fmt.Errorf("unable to get topic %q, %v", topicID, err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: use %w for error wrapping?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good idea but since the calling function bubbles-up any caught errors and wraps them again with %v, it would need changes there too. So I'll leave it as is as its likely not used with errors.Is anywhere or would have caused issues before

@philicious
Copy link
Contributor Author

@embano1 thanks for the review and approval 👍
The changes were tested with our (internal) ETL-pipeline library and events are still happily flowing. Topic/Sub creation wasnt explicitly tested but are covered by tests in cloudevents SDK so imho it should be fine to merge.

you might need to kick-off the remaining CI workflows?

embano1
embano1 previously approved these changes Sep 2, 2025
@embano1
Copy link
Member

embano1 commented Sep 2, 2025

Thx, I'll merge once #1183 is merged as we're upgrading tooling and requiring updated workflows to pass.

See googleapis/google-cloud-go#12218 for reference

Signed-off-by: Philipp Schuler <philipp.schuler@command-b.de>
Signed-off-by: Philipp Schuler <philipp.schuler@command-b.de>
Signed-off-by: Philipp Schuler <philipp.schuler@command-b.de>
@philicious
Copy link
Contributor Author

Thx, I'll merge once #1183 is merged as we're upgrading tooling and requiring updated workflows to pass.

I rebased my branch onto latest master after you merged. I also added a little chore commit for replacing deprecated grpc calls in two of the tests. Hope you dont mind

@embano1
Copy link
Member

embano1 commented Sep 2, 2025

Thx, running CI with auto-merge.

@embano1 embano1 enabled auto-merge September 2, 2025 17:43
@embano1 embano1 merged commit 945d930 into cloudevents:main Sep 2, 2025
9 checks passed
@philicious
Copy link
Contributor Author

@embano1 whats the general release schedule for the cloudevents SDK? (This here kinda blocks our upgrade path)
Best regards!

@embano1
Copy link
Member

embano1 commented Sep 9, 2025

We can cut a release any time cc/ @duglin

@duglin
Copy link
Contributor

duglin commented Sep 12, 2025

I have no objection to creating a new release

@philicious philicious deleted the refactor-pubsubv2 branch September 12, 2025 12:37
@philicious
Copy link
Contributor Author

@embano1 I would like to kindly ask for a new release as there doesnt seem to be any objection :) Thanks in advance for your efforts!

@embano1
Copy link
Member

embano1 commented Sep 22, 2025

On it. Sorry for my silence, been traveling.

@embano1
Copy link
Member

embano1 commented Sep 22, 2025

Done, just don't have the time to create release notes ATM: https://github.com/cloudevents/sdk-go/releases/tag/v2.16.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants