Distinguish initial alarm invocations from retries.

[jqmmes]

This PR adds a new runAlarm parameter to keep track of alarm invocation retries.

[a-robinson]

This code does what it says, but what's the purpose? What's this value going to be used for?

[a-robinson]

This code does what it says, but what's the purpose? What's this value going to be used for?

And is there a reason for choosing a bool over a count of the number of past attempts?

[DaniFoldi]

Hi 👋,

With my somewhat limited c++ knowledge, I couldn't find any references to the js invocation of the alarm handler - this would be useful to have exposed to the handler for observability purposes. Is that something that could be added perhaps? It's the user code throwing that causes a retry anyways, so in theory it could be tracked by user code (try/catch, store and rethrow), but a native counter would be more reliable.

[jqmmes]

This code does what it says, but what's the purpose? What's this value going to be used for?

And is there a reason for choosing a bool over a count of the number of past attempts?

We'll still record each and every invocation internally, I can make it as a counter if you think it's best. Then we would have something like:

invocation X retry 0
invocation X retry 1
invocation X retry 2
invocation X retry 3
...

Instead of

invocation X retry false
invocation X retry true
invocation X retry true
...

[jqmmes]

PR Updated:

• Applied reviewer suggestions.
• Converted retry info from bool to uint32_t counting the current retry number (0 if it's not a retry).
• Rebased

[MellowYarker]

With my somewhat limited c++ knowledge, I couldn't find any references to the js invocation of the alarm handler - this would be useful to have exposed to the handler for observability purposes. Is that something that could be added perhaps? It's the user code throwing that causes a retry anyways, so in theory it could be tracked by user code (try/catch, store and rethrow), but a native counter would be more reliable.

@DaniFoldi the alarm() handler is declared in global-scope.h and we invoke it in global-scope.c++, but yes this is a good idea.