upvote
You wrap it but there must be some kind of call you're making to your API. So are you saying that call fires immediately, races the main wrapped execution, and is therefore done when the execution is finished, therefore neglible latency except for cold starts on extremely short functions?

How does the probe function technically. Inspector API I believe is unavailable on CloudFlare etc.

I once wrote something like this which could work on serverless platforms without the Inspector API. It used Typescript AST transforms to insert no-op listeners at every line, so they would dynamically eval or dump breakpoint style if a listenToLine parameter equalled their line, otherwise no-op. So trivial but not technically zero runtime cost.

reply
yup, it races the main wrapped function.

makes no difference if its cold or warm start. (The latency because of us, not latency in general)

Using AST, that's clever actually! I thought along somewhat similar lines. User tree-sitter. But it needs a build step! not sure how people feel about that :D It changes your source code itself so we'd need a 2 tiered source resolution. Dirty, but doable.

And instead of having this at every line, i did this at "lines of interest" before and after every scope ends.

so at the start/end of an if condition, start/end of fn definiton. it sort of worked, but it slowed down our synthetic benchmarks for "no effect when probes arent there" by more than what i wanted to tolerate and it depended of eval which i thought devs wont accept. and using node-vm slowed it further

But will give another try again. thanks for sharing this!

reply
If I was building this for serverless I would transform with two copies of the code: instrumented and not. Then do one single if statement between them.

If you are transforming anyway you're looking at virtually zero dev time cost and runtime cost when no probe is active of less than 1 ms.

This approach survives any environment I know of and has almost zero runtime cost.

reply