Congrats on the launch! The ability to drop read-only probes into a live service without triggering a painful redeploy is a massive time-saver. Since my workflow relies heavily on cloud-based development, I am curious—how does your SDK handle serverless environments where the container lifecycle is extremely short? Really great concept!

▲

karanraina 3 hours ago | parent [-]

Thanks!

You're correct, serverless is a bit tricky. CPU gets suspended the moment your function returns. The way it works is that you wrap your functions with a wrapper in our sdk.

that wrapper is supposed to track if there's telemetry to be sent, if so.. it sends it, otherwise, return as usual

this makes sure that when there's no active probe, there's no latency added. But when there's an active probe.. ~100-200ms could be added in the worst case if the probe is just before the return.

again, this isnt a problem in non serverless worloads because the CPU is always on.

but since probes are bounded by time and count, this will go away as soon as the time or count condition meets. beats adding new logs and redeploying in my opinion

▲

bluelightning2k 3 hours ago | parent [-]

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.

▲

karanraina 2 hours ago | parent [-]

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!

	▲	bluelightning2k 2 hours ago \| parent [-]
		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.