Repository navigation
Ideas for improving the group() built-in function #884
Description
It would currently be quite difficult to implement, but ideally, once #883 is resolved, we may be able to partially override some of the global options in a group() call. That way we can set different tags for all metrics emitted in that group, or set local default HTTP options once #761 is implemented (especially useful for stuff like authentication).
In a way, something like that already happens, since the group system tag's value is changed inside of the group() call, but it's not flexible or user-configurable at all.
Reacted by Mark Lagendijk
Activity
[-]Overriding some options wuth a group() parameter[/-][+]Overriding some options with a group() parameter[/+]na-- commentedon Jul 31, 2019
I've mentioned in in the linked issue (#891 (comment)), but a users's question on Slack reminded me of that idea to extend this proposal, so it can help with some use cases where users don't want specific metrics measured. Specifically, we should be able to add an option/parameter to the
group()call (or something else) that basically silences all metrics that would have been emitted during the execution of the callback function. I think this should be achievable by replacing the metrics channel in thelib.Stateobject, like howgroup()currently replaces theGroup. Though it's an open question about the issues this approach would have when we have event loops (#882)...[-]Overriding some options with a group() parameter[/-][+]Ideas for improving the group() built-in function[/+]mstoykov commentedon Oct 13, 2023
Given how
groupdoes not work withasyncand we will likely have to figure out somethign for it's current usage and that this will likely have to do with https://github.com/tc39/proposal-async-context and/or goja#AsyncContextTracker.I have opened #3392 where we will explore making this async compatible and hopefully more generic.