-
Notifications
You must be signed in to change notification settings - Fork 950
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 support for firealerts events in Eventarc emulator. #7355
Conversation
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.
After reviewing the code, I'm not sure I'm convinced we need to handle custom and native events separately. The event handling logic for both cases is virtually the same; if we'd like to preserve the metadata identifying which triggers handle custom events vs. native events, we can just keep track of that in the event trigger interface.
Let's take a pass at this together and revisit that part of the design today.
src/emulator/eventarcEmulator.ts
Outdated
); | ||
} | ||
|
||
async triggerNativeEventFunction(event: CloudEvent<any>) { |
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.
I'm noticing that the triggerNativeEventFunction
and triggerCustomEventFunction
have a lot of duplicate logic and this feels like a good opportunity to apply the DRY principle. I think this is what Daniel was referring to in your design doc. Can we refactor this so that they share the same code path?
src/emulator/eventarcEmulator.ts
Outdated
const customEventTriggers = this.customEvents[key] || []; | ||
customEventTriggers.push({ projectId, triggerName, eventTrigger }); | ||
this.customEvents[key] = customEventTriggers; | ||
} else { |
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.
Again here - I don't a compelling reason why we need to track the custom and native events in separate dictionaries.
src/emulator/eventarcEmulator.ts
Outdated
@@ -95,17 +112,33 @@ export class EventarcEmulator implements EmulatorInstance { | |||
}); | |||
}; | |||
|
|||
const publishNativeEventsRoute = `/google/publishEvents`; |
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.
Same here - the native events handler is essentially doing the same job as the custom events handler.
@@ -10,7 +10,7 @@ import { EmulatorRegistry } from "./registry"; | |||
import { FirebaseError } from "../error"; | |||
import { cloudEventFromProtoToJson } from "./eventarcEmulatorUtils"; | |||
|
|||
interface CustomEventTrigger { | |||
interface EmulatedEventTrigger { |
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.
*nit - how about EventarcTrigger? I don't feel strongly about this but it may make sense to apply a more specific naming convention, in case we add other event trigger interfaces for other emulated services.
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.
Looks great - thanks for making these revisions! I'm going to approve, but let's wait for Daniel to take a look before merging
const publishEventsHandler: express.RequestHandler = (req, res) => { | ||
const channel = `projects/${req.params.project_id}/locations/${req.params.location}/channels/${req.params.channel}`; | ||
const isCustom = req.params.project_id && req.params.channel; |
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.
👍
method: "POST", | ||
path: `/functions/projects/${trigger.projectId}/triggers/${trigger.triggerName}`, | ||
body: JSON.stringify(event), | ||
responseType: "stream", |
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.
q: why is the response type here stream?
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.
I am not 100% of this either. I know it is showing up as a diff here, but that's just because I extracted out some of the previous code into a function. I am inclined to leave it this way as it is working fine with supporting the new events and I don't want to break anything that was working previously.
const service = getFunctionService(definition); | ||
const key = this.getTriggerKey(definition); | ||
|
||
switch (service) { |
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.
Note to self/Brian/Daniel - we might need to add PubSub triggers here in to fix #6585
Description
Added support for native events within the event arc emulator and
Scenarios Tested
In a firebase functions project, created the following function:
Ran the emulator suite with:
Then used the following curl command to "publish" an event:
To which the emulator suite properly responded by running the
handlePerformanceAlert
function and logging the event to the emulator logs page.