Event ID not being passed to Conversions API

[mdo5004]

I'm seeing a 0% deduplication rate between the Conversions API and the FBP, but I have confirmed that the Event Name and Event ID being passed by both methods are the same for every event.

On my client, I have an order object with a unique order.id coerced from an integer to a string. I send a Purchase event like so:

const purchaseData = formatPurchaseData(order);
window.fbq('track', 'Purchase', purchaseData, { eventID: `${order.id}` });

The order is also processed on the server and the event is sent to the Conversions API, like so:

  const serverEvent = new ServerEvent()
    .setEventName('Purchase')
    .setEventId(`${order.id}`)
    ...

  console.log('serverEvent._event_id', serverEvent._event_id);
  console.log('serverEvent._event_name', serverEvent._event_name);

  const eventsData = [serverEvent];
  const eventRequest = new EventRequest(access_token, pixel_id).setEvents(
    eventsData,
  );
  console.log(JSON.stringify(eventRequest));
  return eventRequest.execute()

The above console logs log the following:

> serverEvent._event_id 000001
> serverEvent._event_name Purchase
> {
>   "_access_token": "...",
>   "_pixel_id": "...",
>   "_events": [
>     {
>       "_event_name": "Purchase",
>       ...
>       "_event_source_url": "...",
>       "_event_id": "000001",
>       "_action_source": "website"
>     }
>   ],
>   "_partner_agent": null,
>   "_test_event_code": null,
>   "_namespace_id": null,
>   "_upload_id": null,
>   "_upload_tag": null,
>   "_upload_source": null,
>   "_debug_mode": false,
>   "_http_service": null,
>   "_api": {
>     "accessToken": "...",
>     "locale": "en_US",
>     "_debug": false,
>     "_showHeader": false
>   }
> }

It makes me feel confident that the code I've written is working as expected, but we still see a 0% deduplication rate in Events Manager. I don't see a way to truly debug this, as I can't peer directly into the data Meta is collecting from my server + client.

This is probably a duplicate of issue #213 but as that issue is more than 3 years old, I thought I'd open up a new one.