Page MenuHomePhabricator

Bad ATS config led to large volume of 5xx from RESTBase
Closed, ResolvedPublic

Description

Yesterday, a faulty patch to ATS was deployed, but it was rejected by reload_config() because of the syntax error.

This morning, an unrelated but correct change to backend.yaml was deployed; that change involved a restart of ATS, including the bad config from yesterday.

That resulted in requests to /api/rest_v1 being sent to their fallback route, which is RESTBase. RESTBase didn't know what to do with them, so returned errors. Those errors resulted in a page (from ATS for elevated backend errors).

Reverting the faulty ATS change and restarting ATS resolved the incident.

Event Timeline

corto changed the task status from Open to In Progress.
corto triaged this task as High priority.
corto created this object with visibility "acl*security (Project)".
corto created this object with edit policy "acl*security (Project)".
corto changed the task status from In Progress to Open.Mar 25 2026, 7:18 AM

Incident has been resolved, moving status from 'In Progress' to 'Open' so that followup work can be tracked via this task.

Joe subscribed.

The way I see it this was a case of "failure in depth".

  • We are still using restbase as the default fallback for requests to /api/rest_v1; we shouldn't do that anymore imho
  • There is no CI check for validity of lua scripts loaded in trafficserver; some have functional tests but a syntax error should have never passed CI, even in the absence of tests
  • Lua scripts get automatically reloaded by trafficserver. We should have some alerting that tells us when ATS is logging so many lua syntax errors
  • The script that restarts/reloads ATS config when a yaml file is changed should first check there's no error in the configuration, including lua possibly, and refuse restarting ATS unless it's safe to do so.

Tagging the task for the traffic team to create followups.

MatthewVernon renamed this task from restbase outage to Bad ATS config led to large volume of 5xx from RESTBase.Mar 25 2026, 8:39 AM
MatthewVernon updated the task description. (Show Details)
MatthewVernon changed the visibility from "acl*security (Project)" to "Public (No Login Required)".
MatthewVernon changed the edit policy from "acl*security (Project)" to "All Users".

The way I see it this was a case of "failure in depth".

  • We are still using restbase as the default fallback for requests to /api/rest_v1; we shouldn't do that anymore imho

We are aware, changing that is part of the Q4 cleanup for 5.2.2c

There is no CI check for validity of lua scripts loaded in trafficserver; some have functional tests but a syntax error should have never passed CI, even in the absence of tests

this is not accurate, the current tests fail to validate the configuration file, that in fact is a piece of lua code, I'll work on this today

Change #1260667 had a related patch set uploaded (by Vgutierrez; author: Vgutierrez):

[operations/puppet@production] trafficserver: Validate .lua.conf files

https://gerrit.wikimedia.org/r/1260667

Change #1260667 merged by Vgutierrez:

[operations/puppet@production] trafficserver: Validate .lua.conf files

https://gerrit.wikimedia.org/r/1260667

Change #1262152 had a related patch set uploaded (by Scott French; author: Scott French):

[operations/puppet@production] trafficserver: Extend validation for .lua.conf files

https://gerrit.wikimedia.org/r/1262152

Change #1262152 merged by Scott French:

[operations/puppet@production] trafficserver: Extend validation for .lua.conf files

https://gerrit.wikimedia.org/r/1262152

MLechvien-WMF claimed this task.
MLechvien-WMF subscribed.

Closing this as follow up tasks were filed separately