Implement V1 compat API for PubSub #1782

shettyvarun268 · 2025-12-04T19:28:49Z

This PR adds the v1-compatible argument getters (context and message) directly to the v2 Pub/Sub CloudEvent class.
This allows developers to access v1-style arguments via property access, e.g., const { message, context } = event;, for a smoother migration of existing business logic to the v2 function signature.Implementation Details

The v1-compatible context getter is implemented as a lazily-computed property on the CloudEvent object. To correctly construct the v1 EventContext from the v2 event's properties, the following two internal helper functions are introduced:

attachPubSubContext<T>(event: CloudEvent<MessagePublishedData<T>>, topic: string):
Adds the v1-style context property to the v2 event object using Object.defineProperty.
The getter computes the EventContext by mapping v2 properties (event.id, event.time) and by calling getResourceName.
This ensures the context is only computed once upon first access.
getResourceName(event: CloudEvent<MessagePublishedData<any>>, topic: string):
Extracts the full resource name for the v1 EventContext resource object.
It attempts to parse the project ID and topic name from event.source or falls back to environment variables and the function's topic name parameter if necessary.

This is the first of a series of PRs aimed at simplifying the migration from v1 to v2. By introducing this new
onMessagePublished function, we are providing a more robust and flexible way to handle Pub/Sub events in Cloud Functions for Firebase v2.

gemini-code-assist · 2025-12-04T19:29:08Z

Summary of Changes

Hello @shettyvarun268, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a significant enhancement to the v2 Pub/Sub CloudEvent handling by integrating v1-compatible argument accessors. The primary goal is to facilitate a seamless migration for developers transitioning their existing v1 Cloud Functions to the v2 signature. By providing direct property access to message and context in a v1-like manner, it reduces the friction associated with adapting business logic to the new event structure, making the upgrade path more straightforward.

Highlights

V1 Compatibility: Adds v1-compatible context and message getters directly to the v2 Pub/Sub CloudEvent<MessagePublishedData> class.
Migration Simplification: Enables direct property access (e.g., const { message, context } = event;) for smoother migration of existing v1 business logic to v2 function signatures.
Lazy Context Computation: Implements the v1-compatible context getter as a lazily-computed property on the CloudEvent object, ensuring it's only computed upon first access.
New Helper Functions: Introduces two internal helper functions: attachPubSubContext to add the v1-style context and getResourceName to extract the full resource name for the v1 EventContext, including robust fallback logic for project and topic names.
Strategic Initiative: This pull request is the first in a series aimed at simplifying the overall migration process from v1 to v2 Cloud Functions for Firebase.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

shettyvarun268 · 2025-12-04T19:29:57Z

/gemini review

gemini-code-assist

Code Review

This pull request introduces a v1-compatibility layer for v2 Pub/Sub functions by adding a lazily-computed context property to the CloudEvent object. The implementation is well-structured, using Object.defineProperty for lazy evaluation and providing fallbacks for constructing the resource name. I've identified a bug in the resource name construction for a fallback case and a couple of areas for improvement in the tests to make them more robust and accurate. My feedback includes a high-severity fix for the resource name format and medium-severity suggestions to improve test coverage and correctness.

src/v2/providers/pubsub.ts

spec/v2/providers/pubsub.spec.ts

gemini-code-assist

Code Review

The pull request successfully implements V1-compatible API for PubSub events in V2 Cloud Functions, which will greatly assist in migrating existing business logic. The changes introduce "context" and "message" getters to the CloudEvent<MessagePublishedData> class, along with robust helper functions attachPubSubContext and getResourceName to construct the V1 EventContext. The new test cases thoroughly cover the functionality, including handling existing contexts and fallback mechanisms for resource name extraction.

src/v2/providers/pubsub.ts

spec/v2/providers/pubsub.spec.ts

src/v2/core.ts

src/v2/providers/pubsub.ts

src/v2/core.ts

src/v2/providers/pubsub.ts

spec/v2/providers/pubsub.spec.ts

taeold · 2025-12-16T23:15:26Z

spec/v2/providers/pubsub.spec.ts

+
+
+  it("should use 'unknown-project' as fallback for resource name", async () => {
+    delete process.env.GCLOUD_PROJECT;


is this necessary?

Yeah I think we should keep this. In case we receive a malformed event where the EventID is not parsed, this would ensure that the function does not crash. Also considering GCLOUD_PROJECT is an environmental variable, there could be a case when its not populated (?). What do you think?

anything could happen, but it would be extremely rare. My general thinking here is that if we aren't aware of any condition/scenarios where this could happen, then we may choose to fail explicilty and early instead of letting the unknown condition seem like it's working as intended.

Also - i'm not sure if GCLOUD_PROJECT env var is actually used in our logic? Isn't project id extracted from the data included in the cloud event payload?

src/v2/providers/pubsub.ts

src/v2/core.ts

src/v2/providers/pubsub.ts

taeold · 2026-01-08T23:42:19Z

spec/v2/providers/pubsub.spec.ts

+      data,
+    };
+
+    type PubSubCloudEvent = CloudEvent<pubsub.MessagePublishedData> & {


it is pretty uncommon to define a type outside of top-level. I'd suggest just inlining this.

(adding on, there's an argument on whether this specific typing is helpful or not! For testing code, i'd not concern too much with narrowly typing things out)

e.g. message: pubsub.Message<{ hello: "world" }>; could just be message: pubsub.Message; without a lot of loss of type info.

taeold · 2026-01-08T23:57:31Z

spec/v2/providers/pubsub.spec.ts

+
+
+  it("should use 'unknown-project' as fallback for resource name", async () => {
+    delete process.env.GCLOUD_PROJECT;


anything could happen, but it would be extremely rare. My general thinking here is that if we aren't aware of any condition/scenarios where this could happen, then we may choose to fail explicilty and early instead of letting the unknown condition seem like it's working as intended.

Also - i'm not sure if GCLOUD_PROJECT env var is actually used in our logic? Isn't project id extracted from the data included in the cloud event payload?

taeold · 2026-01-08T23:59:40Z

src/v2/providers/pubsub.ts

+ * @param event - The event to add the context to.
+ * @param topic - The topic the event is for.
+ */
+function addV1Compatibility<T>(event: CloudEvent<MessagePublishedData<T>>, topic: string) {


nit* I think I'd prefer name like addV1CompatProperties to be more explicit

taeold · 2026-01-09T00:19:42Z

src/v2/providers/pubsub.ts

+  Object.defineProperty(event, "message", {
+    get: () => (event.data as MessagePublishedData<T>).message,
+  });
+}


can you make sure that the type of event.message is properly typed when using it?

taeold · 2026-01-09T00:20:32Z

src/v2/providers/pubsub.ts

+function getResourceName(event: CloudEvent<MessagePublishedData<any>>, topic: string) {
+  const match = event.source?.match(/projects\/([^/]+)\/topics\/([^/]+)/);
+  const project = match?.[1];
+  const topicName = match?.[2] ?? topic;


nit* this is usally called ID not name

(name refers to fulll resource name)

taeold · 2026-01-09T00:23:10Z

src/v2/core.ts

+
+  /** V1- compatible context of this event.
+   * 
+   * This getter is added at runtime for V1 compatibility.
+   * May be undefined if not set by a provider
+   */
+  readonly context?: EventContext;


I'd rather not make this change

Instead in v2/providers/pubsub.ts, consider defining a new type like this:

type PubSubEvent = CloudEvent<MessagePublishedData<T>> & { context: ... message: ... }

That way, we don't make context property optional as well as be able to incrementally add support for compat properties to each provider

Implement V1 compat API for PubSub

8f1dcda

shettyvarun268 requested review from brittanycho, jhuleatt and taeold December 4, 2025 19:28

gemini-code-assist bot reviewed Dec 4, 2025

View reviewed changes

src/v2/providers/pubsub.ts Show resolved Hide resolved

spec/v2/providers/pubsub.spec.ts Outdated Show resolved Hide resolved

spec/v2/providers/pubsub.spec.ts Outdated Show resolved Hide resolved

gemini-code-assist bot reviewed Dec 4, 2025

View reviewed changes

src/v2/providers/pubsub.ts Outdated Show resolved Hide resolved

Addressing gemini review comments

30e6e10

taeold requested changes Dec 5, 2025

View reviewed changes

jhuleatt reviewed Dec 5, 2025

View reviewed changes

src/v2/core.ts Show resolved Hide resolved

jhuleatt requested a review from egilmorez December 5, 2025 18:57

jhuleatt reviewed Dec 5, 2025

View reviewed changes

src/v2/providers/pubsub.ts Show resolved Hide resolved

jhuleatt reviewed Dec 5, 2025

View reviewed changes

src/v2/core.ts Show resolved Hide resolved

src/v2/providers/pubsub.ts Show resolved Hide resolved

Addressing the PR comments

7222aad

taeold reviewed Dec 17, 2025

View reviewed changes

Addressing the review comments

a50e328

shettyvarun268 requested a review from taeold December 17, 2025 22:33

brittanycho reviewed Dec 19, 2025

View reviewed changes

src/v2/core.ts Outdated Show resolved Hide resolved

src/v2/providers/pubsub.ts Outdated Show resolved Hide resolved

src/v2/providers/pubsub.ts Show resolved Hide resolved

Resolving minor review changes

1de2120

taeold reviewed Jan 9, 2026

View reviewed changes



		it("should use 'unknown-project' as fallback for resource name", async () => {
		delete process.env.GCLOUD_PROJECT;

Implement V1 compat API for PubSub #1782

Are you sure you want to change the base?

Implement V1 compat API for PubSub #1782

Conversation

shettyvarun268 commented Dec 4, 2025

Uh oh!

gemini-code-assist bot commented Dec 4, 2025

Summary of Changes

Highlights

Footnotes

Uh oh!

shettyvarun268 commented Dec 4, 2025

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants