xai-org/x-algorithm · error · RegexThrottledFailure

maximum pending requests reached

Error message

maximum pending requests reached

What it means

RegexThrottledFailure thrown by RegexOptions.apply as admission control: when the number of in-flight regex requests (pendingRequests) is already at config.maximumPendingRequests, new calls are rejected immediately rather than queued.

Source

Thrown at botmaker/src/scala/com/twitter/botmaker/runtime/RegexOptions.scala:65

    .expireAfterAccess(config.cacheExpirationMillis, TimeUnit.MILLISECONDS)
    .build(new CacheLoader[Pair[String, Integer], Try[Pattern]]() {
      override def load(key: Pair[String, Integer]): Try[Pattern] = {
        cacheMissesCounter.incr()
        Try {
          Pattern.compile(key.getFirst, key.getSecond)
        }
      }
    })

  private[this] val regexCache = RegexCache.of(config.timeoutMilis.toInt, patterns)

  private def apply[T](call: => T): T = {

    requestsCounter.incr()

    if (pendingRequests.get >= config.maximumPendingRequests) {
      skippedRequestsCounter.incr()
      throw RegexThrottledFailure("maximum pending requests reached")
    }

    val startTime = runtime.clock.nowMillis

    try {
      pendingRequests.incrementAndGet
      call
    } catch {
      case t: RegexTimeoutException =>
        runtime.logger.warning("RegexTimeout", t.toString)
        timeoutRequestsCounter.incr()
        throw t
      case t: Throwable =>
        runtime.logger.warning("RegexError", t.toString)
        errorRequestsCounter.incr()
        throw t
    } finally {
      pendingRequests.decrementAndGet

View on GitHub (pinned to 24c60942c5)

Solutions

1. If throttling is expected under load, callers should shed load / back off and retry — this is by design
2. Investigate why pending requests are high (downstream latency) before raising limits
3. Increase maximumPendingRequests in RegexConfigs if the service has headroom
4. Add rate limiting upstream so requests fail fast before hitting this guard

Example fix

# before
maximum_pending_requests: 10
# after (only if capacity allows)
maximum_pending_requests: 100

// pre-call: check gauge of pendingRequests vs maximumPendingRequests and shed load early

try regexOptions.apply(call)
catch { case e: RegexThrottledFailure => backoff and retry with jitter; drop if repeated }

When it happens

Trigger: Concurrency of concurrent regex feature evaluations reaching maximumPendingRequests — e.g. a traffic spike, a slow downstream regex service raising latency (requests linger), or maximumPendingRequests configured too low.

Common situations: Peak traffic with tight throttle limits; downstream regex matcher latency regression causing pending count to accumulate; replaying heavy traffic during incident response.

Related errors

• Regex maximumPendingRequests must be greater than 0
• (ScoreType, Entity) ($scoreType, ${entity.toString}) not sup
• SimClusters model version not supported ${modelVersion.name}
• Job config specified EntityType.SemanticCore, but non-semant
• Argument [--entity-type] must be provided. Supported options

AI-assisted analysis of xai-org/x-algorithm@24c60942c5 (2026-08-28). Data as JSON: /api/errors/5157aa110ef7596a. Report an issue: GitHub.