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

Add support for firealerts events in Eventarc emulator. #7355

Merged
merged 18 commits into from
Jul 22, 2024

Conversation

GarrettBurroughs
Copy link
Contributor

Description

Added support for native events within the event arc emulator and

Scenarios Tested

In a firebase functions project, created the following function:

export const handlePerformanceAlert = onThresholdAlertPublished((thresholdAlert) => {
  console.log(thresholdAlert);
});

Ran the emulator suite with:

$ firebase emulators:start

Then used the following curl command to "publish" an event:

curl -X POST -d '
{"events": [
{
  "alerttype": "performance.threshold",
  "id": "",
  "source": "//firebasealerts.googleapis.com/projects/12345",
  "specVersion": "1.0",
  "appid": "",
  "time": "2024-05-31T18:07:36.470521Z",
  "type": "google.firebase.firebasealerts.alerts.v1.published",
  "project": "",
  "data": {
    "@type": "type.googleapis.com/google.events.firebase.firebasealerts.v1.AlertData",
    "createTime": "2024-05-31T18:07:36.470521Z",
    "endTime": "2024-05-31T18:07:36.470521Z",
    "payload": {
      "metricType": "duration",
      "appVersion": "1 (1.0.0)",
      "violationValue": 0.205629,
      "thresholdUnit": "seconds",
      "violationUnit": "seconds",
      "@type": "type.googleapis.com/google.events.firebase.firebasealerts.v1.FireperfThresholdAlertPayload",
      "numSamples": "200",
      "eventName": "custom-trace-3",
      "thresholdValue": 0.15,
      "eventType": "duration_trace",
      "conditionPercentile": 90,
      "investigateUri": ""
    }
  }
}
]}
' http://localhost:9299/google/publishEvents

To which the emulator suite properly responded by running the handlePerformanceAlert function and logging the event to the emulator logs page.

@GarrettBurroughs GarrettBurroughs marked this pull request as draft June 21, 2024 19:30
Copy link
Contributor

@blidd-google blidd-google left a 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.

);
}

async triggerNativeEventFunction(event: CloudEvent<any>) {
Copy link
Contributor

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?

const customEventTriggers = this.customEvents[key] || [];
customEventTriggers.push({ projectId, triggerName, eventTrigger });
this.customEvents[key] = customEventTriggers;
} else {
Copy link
Contributor

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.

@@ -95,17 +112,33 @@ export class EventarcEmulator implements EmulatorInstance {
});
};

const publishNativeEventsRoute = `/google/publishEvents`;
Copy link
Contributor

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 {
Copy link
Contributor

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.

Copy link
Contributor

@blidd-google blidd-google left a 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;
Copy link
Contributor

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",
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@GarrettBurroughs GarrettBurroughs marked this pull request as ready for review July 2, 2024 14:57
const service = getFunctionService(definition);
const key = this.getTriggerKey(definition);

switch (service) {
Copy link
Contributor

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

@GarrettBurroughs GarrettBurroughs enabled auto-merge (squash) July 22, 2024 17:49
@GarrettBurroughs GarrettBurroughs merged commit de1814f into master Jul 22, 2024
41 checks passed
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