Limiter extension API interfaces and implementation helpers (draft 5) #13051

jmacd · 2025-05-20T01:05:49Z

Description

Draft demonstrating the following advances on the previous draft:

Base limiter is the MustDeny function as a stand-alone, like memory limiter extension/processor would use.
Rate/Resource limiters have a single non-blocking interface
Helper functions wrap the non-blocking interfaces with blocking forms
Limiter middleware helpers for HTTP and gRPC revived from earlier draft
Basic rate limiter based on golang.org/x/time/rate
Basic resource limiter based on collector-contrib/internal/otelarrow/admission2
More-consistent functional style
Suggested configmiddleware integration
memorylimiterextension

Follows drafts
1: #12558
2: #12633
3: #12700
4: #12953

Link to tracking issue

Part of #9591.
Part of #12603.

Testing

NONE: This is a demonstration, smaller PRs will be broken apart and tested individually if reviewers like the look of this, the full assembly.

Documentation

Updated.

…tor into jmacd/limiter_v4

…tor into jmacd/limiter_v5

bogdandrutu

In general LGTM extensionlimiter package, for the "limiterhelper" only looked very high level and I will do a more deeper review after we go over the first round of comments related to the main extensionlimiter package.

bogdandrutu · 2025-05-26T06:22:28Z

extension/extensionlimiter/config.go

+// providers with Options and add a Config type, but none are
+// supported yet and this PR contains only interfaces, not need for
+// options in core repository components.
+type Option interface {


nit: I would name the file option not config.

bogdandrutu · 2025-05-26T06:25:03Z

extension/extensionlimiter/rate.go

+var _ RateLimiterProvider = struct {
+	GetRateLimiterFunc
+	GetBaseLimiterFunc
+}{}


nit: Not sure these kind of checks are relevant to be enforced here.

bogdandrutu · 2025-05-26T06:29:11Z

extension/extensionlimiter/extensionlimiter.go

+
+// BaseLimiter is for checking when a limit is saturated.  This can be
+// called prior to the start of work to check for limiter saturation.
+type BaseLimiter interface {


nit: Rename to BasicLimiter? or Limiter?

Reasoning: For me "base" means that it will be embedded into something else in order to use it, and cannot be used as a standalone. Please correct me if I am wrong.

Thanks. I'm open to either of these, and I agree with your reasoning that "base" isn't great. @axw has suggested that the type and the method name should be related, so if we have Limiter then the API method should be Limit(), if we have Checker it should be Check(), however I find it difficult to apply this pattern to MustDeny. Should this be something else completely, like SaturationChecker with a method named CheckSaturation as @axw proposed?

To explain my thought process:

I would typically name interfaces after a capability, hence naming the interface after a method. This is also suggested in https://go.dev/doc/effective_go#interfaces_and_types:

Interfaces with only one or two methods are common in Go code, and are usually given a name derived from the method, such as io.Writer for something that implements Write.

So to me, RateLimiter and ResourceLimiter feel natural, but BaseLimiter does not -- you're not limiting a base. Also, something like a "base" sounds like a mixin type, which would be relevant for implementation (e.g. a struct) rather than the capability/behaviour (interface).

It seems to me that the ability to check saturation is the capability here, hence SaturationChecker/CheckSaturated.

It's also possible that we don't really need to expose this interface at all, but just have a saturation check method on each of RateLimiter and ResourceLimiter. See also my other questions about BaseLimiter.

bogdandrutu · 2025-05-26T06:37:46Z

extension/extensionlimiter/README.md

+1. Network bytes
+2. Request count
+3. Request items
+4. Memory size


nit: "Request bytes" instead of memory size?

OK, so it'll be

Network bytes (compressed)

Request bytes (uncompressed)

Still, I want to document this as the amount of memory used by the request, not the uncompressed size of the payload (even though it will often equal this value). For a stream protocol (e.g., OTel-Arrow) there will be memory in the stream state that is referred to by the request (e.g., dictionaries) in such a way that:

a. The uncompressed size of the payload will underestimate the memory held by the request
b. The uncompressed size of the OTLP object will overestimate the memory helped by the request

Therefore, components in special circumstances should use judgement: limit by how much memory is tied up by the request in the pipeline, and prefer to overestimate than to underestimate. As an example, repeated requests in an OTel-Arrow stream will refer to the same dictionary entries, meaning a precise estimate of memory referenced by individual requests will overestimate how much is used by a pipeline, due to aliasing within the pipeline.

bogdandrutu · 2025-05-26T06:41:30Z

extension/extensionlimiter/README.md

+interface, and callers are expected to check for saturation by
+invoking `MustDeny` before making individual requests with the limiter.


I would like to include the idea of "as early as possible" into this explanation.

bogdandrutu · 2025-05-26T06:58:00Z

extension/extensionlimiter/README.md

+be called at the proper time, then any kind of limiter can be applied
+in the form of a `ResourceLimiter`.  If the extension is a basic or
+rate limiter in this scenario, use the `BaseToResourceLimiterProvider`
+or `RateToResourceLimiterProvider` adapters.


I commented in the BaseToResourceLimiterProvider for some issues that I can imagine, but in general I am not sure the path is to make all look the same vs have helpers for the 3 types independent.

The approach I've taken is to provide every possible conversion function, which is a fairly small set. BaseToRate, BaseToResource, or RateToResource providers are for situations where LimiterWrapper can't be used (these are "independent", in the sense you mean it, I think), in which case circumstances vary. Two examples follow for Rate and Resource limits.

As pointed at here, middleware is often in a place where only a Rate limit can be applied -- typically for compressed bytes -- and in this case BaseToRate applies (e.g., to adapt memorylimiterextension for middleware).

In scenarios where LimiterWrapper does not apply -- having to do with flow control (e.g. for stream backpressure) -- but where the Resource limiter can be applied because the application is able to release after the request finishes. Here, a Resource limiter interface should be preferred because its interface can be adapted from all the others. In these cases you will use RateToResource and BaseToResource.

bogdandrutu · 2025-05-26T07:00:57Z

extension/extensionlimiter/README.md

+flow and resource usage through extensions which are configured
+through middleware and/or directly by pipeline components.
+
+## Overview


One of the top section should be for "end users" how to configure limiters in some of the most common cases.

I will work on this -- although I haven't actually produced anything for end users that is new here, only the memorylimiterextension could be documented (and it is already linked below).

I would agree to update this with links to the implementations. I would like to request input from @axw on this topic, because while I have created helper implementations of the rate-limiter (from golang.org/x/time/rate) and the resource-limiter. Both of these have two numeric parameters, and we still have to discuss how a real limiter will be configured, which will lead back to our open questions (e.g., how to configure the limiter based on client metadata, how to configure the limiter based on the component name or the signal type?).

bogdandrutu · 2025-05-26T07:01:29Z

extension/extensionlimiter/README.md

+
+### Built-in limiters
+
+#### Base


nit: Called this basic at the beginning of the document, please be consistent.

Yes, I've been inconsistent. See https://github.com/open-telemetry/opentelemetry-collector/pull/13051/files/ba136deb9590d6fc5999c1af548f59965cbd0599#r2106643694.

bogdandrutu · 2025-05-26T07:06:35Z

extension/extensionlimiter/README.md

+#### OTLP receiver
+
+Limiters applied through middleware are an implementation detail,
+simply configure them using `configgrpc` or `confighttp`. For the
+OTLP receiver (e.g., with two `ratelimiter` extensions):
+
+```yaml
+extensions:
+  ratelimiter/limit_for_grpc:
+    # rate limiter settings for gRPC
+  ratelimiter/limit_for_grpc:
+    # rate limiter settings for HTTP
+
+receivers:
+  otlp:
+    protocols:
+      grpc:
+        middlewares:
+        - ratelimiter/limit_for_grpc
+      http:
+        middlewares:
+        - ratelimiter/limit_for_http
+```
+
+Note that the OTLP receiver specifically supports multiple protocols
+with separate middleware configurations, thus it configures limiters
+for request items and memory size on a protocol-by-protocol basis.


Please bear with me on this:

I am trying to evaluate if for end users (not how we implement it, which we can do with same structs) they would like to see:

extensions: ratelimiter/limit_for_grpc: # rate limiter settings for gRPC ratelimiter/limit_for_grpc: # rate limiter settings for HTTP receivers: otlp: protocols: grpc: middlewares: - ratelimiter/limit_for_grpc http: middlewares: - ratelimiter/limit_for_http

OR

extensions: ratelimiter/limit_for_grpc: # rate limiter settings for gRPC ratelimiter/limit_for_grpc: # rate limiter settings for HTTP receivers: otlp: protocols: grpc: limiters: - ratelimiter/limit_for_grpc http: limiters: - ratelimiter/limit_for_http

Suggestion being in confighttp/configgrpc to add a Limiters []configmiddleware.Config mapstructure:"limiters,omitempty" similar with https://github.com/open-telemetry/opentelemetry-collector/blob/main/config/configgrpc/configgrpc.go#L111 but just call it Limiters.

This is a side-note, but a relevant one.

Keep in mind that our present definition for configmiddleware.Config is

// Middleware defines the extension ID for a middleware component. type Config struct { // ID specifies the name of the extension to use. ID component.ID `mapstructure:"id,omitempty"` // prevent unkeyed literal initialization _ struct{} }

which means the config reads with an id like:

grpc: middlewares: - id: ratelimiter/limit_for_grpc

Does squash support what you've written? Otherwise the way it reads, I think you want something like

type Config = component.ID

instead of a struct for middleware config.

As for your question about separating limiters and middleware, I think we should focus on the HTTP case, where it is pretty typical to interleave limiters and other kinds of middleware. There is a potential to refactor confighttp so that some of the existing setup would move into middleware components, for example:

compression middleware

opentelemetry instrumentation

at this point, more questions are raised, because we have discussed limiting by both compressed and uncompressed weights. gRPC gives you compressed and uncompressed in the same stats handler call, but HTTP does compression in middleware, so the network-bytes limit has to be applied before middleware.

In my presentation here, I've implemented "memory_size" -- you suggested request_bytes, sure -- in the receiver. If we want to implement request-size earlier, in the middleware, then we need to configure HTTP limiters before and after the compression middleware.

For this reason, I think limiters should remain in the list of middleware.

For a receiver that otherwise does not use middleware, I think it would be appropriate to follow your example above, that is to have a Limiters []configmiddleware.Config field where we expect to find only limiters.

If you agree, I would file separate tracking issues for the process of moving compression and/or opentelemetry instrumentation into middleware components. This would allow building the collector with alternative compression libraries and/or OTel SDKs, too 😀.

Jmacd's comment makes me feel sympathetic to just putting everything in a middlewares list

In my ideal world, users should be able to configure component-specific rate limiters independently of transport. Maybe they use middleware that uses the same limiter extension, maybe not -- the user should be able to choose.

I would also want to get rid of the "StandardNotMiddlewareKeys" function and leave it to users to choose which limits they want to apply. This can be done by having multiple, specific limiter configurations. e.g.:

extensions: ratelimiter/limit_for_grpc: # rate limiter settings for gRPC ratelimiter/limit_for_http: # rate limiter settings for HTTP ratelimiter/limit_for_otlp: # rate limiter settings for OTLP, independent of transport receivers: otlp: # limiters holds OTLP-specific limiters. For transport-level limiters, configure middleware. limiters: # requests defines a limiter for processing OTLP requests (batches), independent of signal. requests: ratelimiter/limit_for_otlp # items defines a limiter for processing OTLP items: log records, spans, data points, profile samples items: ratelimiter/limit_for_otlp # bytes defines a limiter for processing OTLP-encoded bytes. bytes: ratelimiter/limit_for_otlp protocols: grpc: middlewares: - ratelimiter/limit_for_grpc http: middlewares: - ratelimiter/limit_for_http

If you agree, I would file separate tracking issues for the process of moving compression and/or opentelemetry instrumentation into middleware components.

Yes please. FWIW, we just internally found a need to do the same for auth, IMO that would be good to have too.

bogdandrutu · 2025-05-26T07:09:20Z

extension/extensionlimiter/README.md

+  scraper:
+    http:
+      middlewares:
+      - ratelimiter/scraper


I know you will tell me "I told you", but how can we configure limiters for non grpc/http scrapers like hostmetrics/filebased?

... 😂 I mean yes, the point of this section was to answer your question. We could go with either of the options you presented, also I made the mistake about id: here too: we should think about whether we want to eliminate the id: prefix, see https://github.com/open-telemetry/opentelemetry-collector/pull/13051/files/ba136deb9590d6fc5999c1af548f59965cbd0599#r2106696658.

jmacd · 2025-05-27T15:51:11Z

Note to incorporate feedback in #12953 (review)

MovieStoreGuy · 2025-06-06T02:05:02Z

extension/extensionlimiter/limiterhelper/base.go

+					return struct {
+						extensionlimiter.WaitTimeFunc
+						extensionlimiter.CancelFunc
+					}{}, nil


I would strongly advise against anon struct definitions here, please move the definition to be a Nop type.

axw

Sorry for the delay. Overall I think it's looking good.

I left a few related questions about BaseLimiter - it feels like it could be removed, and left to extensions to present either a RateLimiter or ResourceLimiter that does something specific to that extension where there's no natural rate or resource.

I left a suggestion for how we could structure the component-specific limits vs. transport-specific limits, which I think also provides an answer to @bogdandrutu's question about scraper receivers.

axw · 2025-06-06T07:41:00Z

extension/extensionlimiter/extensionlimiter.go

+
+// BaseLimiter is for checking when a limit is saturated.  This can be
+// called prior to the start of work to check for limiter saturation.
+type BaseLimiter interface {


To explain my thought process:

I would typically name interfaces after a capability, hence naming the interface after a method. This is also suggested in https://go.dev/doc/effective_go#interfaces_and_types:

Interfaces with only one or two methods are common in Go code, and are usually given a name derived from the method, such as io.Writer for something that implements Write.

So to me, RateLimiter and ResourceLimiter feel natural, but BaseLimiter does not -- you're not limiting a base. Also, something like a "base" sounds like a mixin type, which would be relevant for implementation (e.g. a struct) rather than the capability/behaviour (interface).

It seems to me that the ability to check saturation is the capability here, hence SaturationChecker/CheckSaturated.

axw · 2025-06-06T08:25:39Z

extension/extensionlimiter/rate.go

+//
+// See the README for more recommendations.
+type RateLimiter interface {
+	// ReserveRate is modeled on pkg.go.dev/golang.org/x/time/rate#Limiter.ReserveN


I would caution against overindexing on that package. I quite like its API, but reservation is easy for local rate limiters, not so easy for distributed ones.

We wouldn't be able to adapt our rate limiter to this API, since Gubernator just does not support reservation. Similarly, it wouldn't be possible to use https://pkg.go.dev/github.com/juju/ratelimit (though I don't think we would be able to use it here anyway -- it's LGPL)

IIUC, your goal is to enable non-blocking behaviour, and not specifically to enable reservation/cancellation -- is that correct? If so, it is possible to make the rate limiters non-blocking without supporting reservations. For example, you could return a duration that the caller is expected to wait before proceeding, like:

type RateLimiter interface { // RateLimit reserves n tokens, either immediately or in the future, // returning the duration that the caller must wait before those tokens // are available. RateLimit(ctx context.Context, n int) (time.Duration, error) }

Internally, a golang.org/x/time/rate-based implementation would create a reservation to implement this interface.

The key difference here is that once you've requested the limit, there's no going back.

axw · 2025-06-06T08:38:39Z

extension/extensionlimiter/limiterhelper/wrapper.go

+			if lim == nil {
+				return nil, nil
+			}
+			blocking := NewBlockingResourceLimiter(lim)


This feels a bit too prescriptive. The wrapper API seems like it should be orthogonal to whether the limiter is blocking or non-blocking. Then for example, users could configure their receivers to either return immediately with 429 or block. Either way I would expect this limiter provider to be used, it would just be a matter of whether it internally blocks or not.

axw · 2025-06-06T09:07:31Z

extension/extensionlimiter/limiterhelper/middleware.go

+// MiddlewareToBaseLimiterProvider returns a base limiter provider
+// from middleware. Returns a package-level error if the middleware
+// does not implement exactly one of the limiter interfaces (i.e.,
+// rate or resource).
+func MiddlewareToBaseLimiterProvider(ext extensionlimiter.BaseLimiterProvider) (extensionlimiter.BaseLimiterProvider, error) {
+	return getMiddleware(
+		ext,
+		identity[extensionlimiter.BaseLimiterProvider],
+		baseProvider[extensionlimiter.RateLimiterProvider],
+		baseProvider[extensionlimiter.ResourceLimiterProvider],
+	)
+}


Would anything ever need just a BaseLimiter? I'm wondering if the BaseLimiterProvider interface is actually needed, or if clients can request either a RateLimiterProvider or a ResourceLimiterProvider, given an extension.

axw · 2025-06-06T09:17:07Z

extension/extensionlimiter/limiterhelper/base.go

+// BaseToRateLimiterProvider allows a base limiter to act as a rate
+// limiter.
+func BaseToRateLimiterProvider(blimp extensionlimiter.BaseLimiterProvider) extensionlimiter.RateLimiterProvider {


I think this name needs to be a bit more descriptive about the behaviour. A key aspect is that if the limit is not currently saturated, any number of concurrent operations may will be allowed through: the operation will not directly affect the saturation. (Maybe indirectly, e.g. by increasing memory usage)

I also wonder if there really can be a one-size-fits-all for this? Perhaps it should be left to each extension to choose how to adapt? Do you foresee anything other than memorylimiter implementing only BaseLimiter and neither RateLimiter nor ResourceLimiter?

axw · 2025-06-06T09:18:29Z

extension/extensionlimiter/extensionlimiter.go

+
+// BaseLimiter is for checking when a limit is saturated.  This can be
+// called prior to the start of work to check for limiter saturation.
+type BaseLimiter interface {


It's also possible that we don't really need to expose this interface at all, but just have a saturation check method on each of RateLimiter and ResourceLimiter. See also my other questions about BaseLimiter.

axw · 2025-06-06T10:05:55Z

extension/extensionlimiter/README.md

+#### OTLP receiver
+
+Limiters applied through middleware are an implementation detail,
+simply configure them using `configgrpc` or `confighttp`. For the
+OTLP receiver (e.g., with two `ratelimiter` extensions):
+
+```yaml
+extensions:
+  ratelimiter/limit_for_grpc:
+    # rate limiter settings for gRPC
+  ratelimiter/limit_for_grpc:
+    # rate limiter settings for HTTP
+
+receivers:
+  otlp:
+    protocols:
+      grpc:
+        middlewares:
+        - ratelimiter/limit_for_grpc
+      http:
+        middlewares:
+        - ratelimiter/limit_for_http
+```
+
+Note that the OTLP receiver specifically supports multiple protocols
+with separate middleware configurations, thus it configures limiters
+for request items and memory size on a protocol-by-protocol basis.


In my ideal world, users should be able to configure component-specific rate limiters independently of transport. Maybe they use middleware that uses the same limiter extension, maybe not -- the user should be able to choose.

I would also want to get rid of the "StandardNotMiddlewareKeys" function and leave it to users to choose which limits they want to apply. This can be done by having multiple, specific limiter configurations. e.g.:

extensions: ratelimiter/limit_for_grpc: # rate limiter settings for gRPC ratelimiter/limit_for_http: # rate limiter settings for HTTP ratelimiter/limit_for_otlp: # rate limiter settings for OTLP, independent of transport receivers: otlp: # limiters holds OTLP-specific limiters. For transport-level limiters, configure middleware. limiters: # requests defines a limiter for processing OTLP requests (batches), independent of signal. requests: ratelimiter/limit_for_otlp # items defines a limiter for processing OTLP items: log records, spans, data points, profile samples items: ratelimiter/limit_for_otlp # bytes defines a limiter for processing OTLP-encoded bytes. bytes: ratelimiter/limit_for_otlp protocols: grpc: middlewares: - ratelimiter/limit_for_grpc http: middlewares: - ratelimiter/limit_for_http

If you agree, I would file separate tracking issues for the process of moving compression and/or opentelemetry instrumentation into middleware components.

Yes please. FWIW, we just internally found a need to do the same for auth, IMO that would be good to have too.

jmacd added 24 commits April 30, 2025 13:20

lint

2eb77f5

close

04380f4

readme

7444153

move multi-limiter

e597fa1

data-dep example

e6675c8

lint

ac0d1ec

lint

b3e4554

Merge branch 'main' of github.com:open-telemetry/opentelemetry-collec…

ffad28a

…tor into jmacd/limiter_v4

wip split Checker (was Limiter)

b8ed41d

rename

d07da61

move wrapper into limiterhelper

f3a2f2f

style

8b31cd6

call checker once

40aee98

checker all keys

137be27

readme

4a44264

Merge branch 'main' of github.com:open-telemetry/opentelemetry-collec…

f873ca8

…tor into jmacd/limiter_v4

Merge branch 'main' of github.com:open-telemetry/opentelemetry-collec…

3194963

…tor into jmacd/limiter_v4

Checker to BaseLimiter

0fcdf27

create config.go

0348677

weightset

144b866

add non-blocking interface resembling x/time/rate

3edd1d8

http

785e665

grpc

294dbc5

draft with non-blocking limiters and blocking helpers

193bd60

github-actions bot added the receiver/otlp label May 20, 2025

jmacd changed the title ~~Jmacd/limiter v5~~ Limiter extension API interfaces and implementation helpers (**draft 5**) May 20, 2025

jmacd added 4 commits May 20, 2025 13:57

Work on readme

7bdee79

wip

5ddab1c

comments

1fd254c

goroutine -> AfterFunc

68c4cce

jmacd added 2 commits May 21, 2025 17:40

config middleware / otlp receiver update

c11e76e

memorylimiter extension

ecdc9d5

github-actions bot added the extension/memorylimiter label May 22, 2025

more readme; fewer open questions

d529eb0

jmacd marked this pull request as ready for review May 22, 2025 02:45

jmacd requested a review from a team as a code owner May 22, 2025 02:45

jmacd requested a review from evan-bradley May 22, 2025 02:45

jmacd added 2 commits May 22, 2025 09:30

Merge branch 'main' of github.com:open-telemetry/opentelemetry-collec…

54f587b

…tor into jmacd/limiter_v5

bugs fixed

23b4f2c

jmacd force-pushed the jmacd/limiter_v5 branch from d8f4b63 to 23b4f2c Compare May 22, 2025 17:54

readme

ba136de

bogdandrutu reviewed May 26, 2025

View reviewed changes

jmacd mentioned this pull request May 27, 2025

Limiter extension API interfaces (**draft 4**) #12953

Closed

MovieStoreGuy reviewed Jun 6, 2025

View reviewed changes

axw reviewed Jun 6, 2025

View reviewed changes

		interface, and callers are expected to check for saturation by
		invoking `MustDeny` before making individual requests with the limiter.

Limiter extension API interfaces and implementation helpers (**draft 5**) #13051

Are you sure you want to change the base?

Limiter extension API interfaces and implementation helpers (**draft 5**) #13051

Uh oh!

Conversation

jmacd commented May 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Link to tracking issue

Testing

Documentation

Uh oh!

bogdandrutu left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jmacd commented May 27, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

axw left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Limiter extension API interfaces and implementation helpers (draft 5) #13051

Limiter extension API interfaces and implementation helpers (draft 5) #13051

jmacd commented May 20, 2025 •

edited

Loading