fix(node): Make sure we use same ID for checkIns

[AbhiPrasad]

Based on work in #8039, this PR fixes a bug where we were adding a unique ID to every check in, which is incorrect behaviour. Instead we now return a checkInId every time a check in is captured, which can be used to link check ins together.

Example:

// 🟡 Notify Sentry your job is running:
const checkInId = Sentry.captureCheckIn({
  monitorSlug: '<monitor-slug>',
  status: 'in_progress',
});

// Execute your scheduled task here...

// 🟢 Notify Sentry your job has completed successfully:
Sentry.captureCheckIn({
  checkInId,
  monitorSlug: '<monitor-slug>',
  status: 'ok',
});

[lforst]

You could theoretically call captureCheckIn with status "in_progress" but not provide a checkInId. We should couple those types. Not coupling would be very opaque for users why things are not working.

[AbhiPrasad]

yup refined with 33fd221

[lforst]

I think that commit is on the wrong branch

[AbhiPrasad]

🤦

[lforst]

Do we want to make the ID required for FinishedCheckIns?

[lforst]

Honestly, why the hell do we need both an ID and a name??

[AbhiPrasad]

Do we want to make the ID required for FinishedCheckIns

It makes the DX worse, so no. This is because technically an ID can be undefined if the client is disabled (so the first captureCheckIn will return undefined in that case)

Honestly, why the hell do we need both an ID and a name??

It's because you can have multiple crons with the same name fire at the same time, the id helps make sure that this works.

[lforst]

Just to explain the point I was making here because I think you misunderstood me here: For the finished checkins we theoretically don't need to send the id AND the slug since we can already map from id to slug in the product.

I still stand by my point that we should not be required to send both but I'll approve this to unblock so that our current implementation is not busted.