Propagate request context through nested procedure calls

[petermasking]

Currently, when a procedure (function) is executed, the request object is passed as thisArg. This allows header information to be forwarded transparently to remote implementations.

This works when the procedure directly invokes a remote implementation. However, if there is an intermediate sub-function, the thisArg is not propagated, so the request data is lost.

For the next iteration, we want to ensure that request data is consistently available in remote implementations, regardless of how the call chain is structured.

Before selecting an approach, we need to research the available options and evaluate their feasibility.

[petermasking]

After some research, we decided to use request binding at the trace level rather than propagating request data via thisArg. We evaluated several approaches to find one that works reliably across major JavaScript engines.

The current preferred strategy is to create an execution scope with a unique identifier that is exposed in the stack trace, allowing the request origin to be traced.

Our test setup looks like this:

function remote()
{
    console.log(new Error().stack);
}

function local()
{
    remote();
}

function createExecutionScope(func, traceName)
{
    const ExecutionScope = class
    {
        #func;

        constructor(func)
        {
            this.#func = func;
        }

        [traceName](args)
        {
            return this.#func.apply(undefined, ...args);
        }

        execute(...args)
        {
            return this[traceName](args);
        }
    }

    return new ExecutionScope(func);
}

const instance = createExecutionScope(local, '#trace_012345');
instance.execute();

This works in most major browsers.

Chrome

Error
    at remote (test.mjs:4:17)
    at local (test.mjs:9:5)
    at #trace_012345 (test.mjs:25:31)
    at ExecutionScope.execute (test.mjs:30:35)
    at test.mjs:39:10

Firefox

remote@http://127.0.0.1:5500/test.mjs:4:17
local@http://127.0.0.1:5500/test.mjs:9:5
#trace_012345@http://127.0.0.1:5500/test.mjs:25:31
execute@http://127.0.0.1:5500/test.mjs:30:35
@http://127.0.0.1:5500/test.mjs:39:10

This allows us to maintain an internal list of active requests indexed by their identifier, enabling remote implementations to look up the origin request when needed.

Note: The request must be removed from the list after procedure execution completes to prevent memory leaks or stale state.