Ivan

Unfortunately, this is a general limit for k6, the core repository already tracks it on https://github.com/grafana/k6/issues/587. I close this issue to keep it as a centralized place.

I close as the demand seems not very high at the moment. It sounds aligned with the general demand of the gRPC protocol, where there are some orders of magnitude...

Hey @rybbchao, I'm going to close this issue as it seems is not under active development. Feel free to re-open if you find the time to re-work the changes. Thanks...

@yorugac is this feature required on the output side? I think the output could just rely on the [SystemTags](https://k6.io/docs/using-k6/k6-options/reference#system-tags) provided by k6. If the user wants to reduce the number...

Currently, we're not planning to implement this. As we mentioned, we want to address it with a wider approach. If required, use one of the collector available out there to...

The major issues with this have been resolved. The output aggregates all the samples of the same series seen during the same configured push interval. I keep it open mostly...

Currently, this is not planned on our short-term roadmap. It doesn't seem optimal to delegate this functionality to k6, as it would introduce additional complexity on error handling. Out there,...

Ideally, if possible, we should centralize the visualization and inject the data source's queries. In this way, keeping the extensions synced would be easier. In this way, we could define...

>The name of the mode is not typescript, because it can also be used with JavaScript files. It's not esbuild because I followed the naming convention, the extended compatibility mode...

If this is the case, should we go with something like `experimental-extended-v2`?