Possible regression: Duplicate Firestore trigger event ids

[REQUIRED] Version info

node: v8.11.1

firebase-functions: 2.0.5

firebase-tools: 6.3.0

firebase-admin: 6.0.0

[REQUIRED] Test case

With the following onCreate triggers deployed for the same document:

const functions = require('firebase-functions');
const admin = require('firebase-admin');

exports.functionOne = functions.firestore
  .document('/users/{userId}')
  .onUpdate((snapshot, context) => {
    console.log(context.eventId);
  });

exports.functionTwo = functions.firestore
  .document('/users/{userId}')
  .onUpdate((snapshot, context) => {
    console.log(context.eventId);
  });

[REQUIRED] Steps to reproduce

With the above functions deployed, create a document in the users collection.

[REQUIRED] Expected behavior

The two functions should be called with unique event ids. These should be logged and be different.

[REQUIRED] Actual behavior

The two logged event ids are the same.

Description

I’m not sure if this report belongs in this repo, but using this was where the problem appeared and I wasn’t able to see that the event id comes from elsewhere that I can access.

At some point recently, triggers on the same document like defined above started getting the same event id. Previously if there were multiple triggers for the same document, the event id would have an appended part (like long-uuid-0 and long-uuid-1).

This change caused the code we use to make the functions idempotent to no longer work, and only the first function that reacted to the change was allowed to run.

I haven’t been able to find information about this change anywhere so far, so I’d be curious if there’s anywhere I’ve missed.

Thanks!

[mbleigh]

process.env.FUNCTION_NAME should contain the name of the executing function.

[inlined]

Hi Kimroen, the event ID has been a slightly nebulous subject and we’re trying to help add more meaning/standardization to something that was previously not crisply defined.

I completely understand why the event ID alone might be getting used as an idempotency key. I think I myself have recommended the shortcut. The Event ID describes the thing that happened, not the thing that happened + the thing handling it. This means that in the uncommon case where you will have two event handlers talking to the same services (and thus have a potential key collision) you’ll want to add some extra info to your Event ID to make the idempotency key.

This is a bit of extra work for your use case, but seems like the right tradeoff. It’s always possible to rehash something with new info (e.g. creating an idempotency key from event ID + Function) but you can’t undo this operation on an opaque hash. For example, this design is the only way your functions could intentionally coordinate their work so that a 3rd function handles the results of the first two on a per-event basis.