GLOBAL_MAX_CONCURRENT_REQ VIES error: what it means and what to do

Not retried by AvatcadoAvailability error
By Remco from Avatcado

GLOBAL_MAX_CONCURRENT_REQ means VIES did not process your check because the whole service reached its maximum number of concurrent requests. The VAT number was not checked, so never treat it as invalid. Slow down, wait before retrying, and keep the result pending until a check succeeds.

Your Request for VAT validation has not been processed; the maximum number of concurrent requests has been reached. Please re-submit your request later

VIES checkVatService WSDL (fault list)

What it means

VIES documents the fault as the maximum number of concurrent requests having been reached, so the request was not processed. It explains MS_MAX_CONCURRENT_REQ in terms of traffic towards one member state and this fault in terms of high traffic on the web application.

What causes it

High traffic on VIES. A related fault, GLOBAL_MAX_CONCURRENT_REQ_TIME, reports the limit for the current timeslot, and the VIES test service lists the two as separate errors.

How to handle it

  • Treat the result as unknown, never as invalid.
  • Pause your VIES traffic before retrying, with backoff and random jitter, so a batch of checks does not retry all at once.
  • Spread bulk validation jobs out over time.
  • Stop after a bounded number of attempts and queue the check for later.

What Avatcado does when VIES returns GLOBAL_MAX_CONCURRENT_REQ

Avatcado does not retry GLOBAL_MAX_CONCURRENT_REQ inside the request. It is the one availability error Avatcado leaves alone, because an immediate retry is one more concurrent request to a service that has just reported too many.

If VIES still has no answer, Avatcado asks the country's national tax register on the Pro and Business plans, for the 10 EU countries that have one (listed on the coverage page), and on every plan it falls back to the most recent stored result for that number. When neither can answer, the API returns a 503 with the code upstream_member_state_unavailable, and the call does not count against your quota. A check that ends in an availability error is never stored as an answer. A request that carries requester_vat_number skips both fallbacks by default, because a consultation number has to come from a completed VIES check.

How often Avatcado sees GLOBAL_MAX_CONCURRENT_REQ

GLOBAL_MAX_CONCURRENT_REQ was too rare in Avatcado's production traffic over the last 90 days to report figures for it.

Frequently asked questions

Why does Avatcado not retry GLOBAL_MAX_CONCURRENT_REQ?

Because the fault says VIES as a whole is at its concurrency limit, and an immediate retry is one more concurrent request. Avatcado retries the other availability errors inside the request and leaves this one alone. A request that hits it moves on to the national register on the Pro and Business plans, for the countries that have one, or to the most recent stored result, and ends in a 503 that does not count against your quota when neither exists.

Is GLOBAL_MAX_CONCURRENT_REQ caused by my traffic alone?

VIES's documentation describes it as high traffic on the web application and does not say the limit is counted per caller. Treat it as a signal to slow down all of your VIES calls for a while, since every request you send counts towards the traffic VIES is reporting.

Keep reading

Sources

Validate VAT numbers with the retries and fallback built in.

National register fallback on Pro and Business. Free tier: 500 validations a month.