Updates can no longer be dequeued on Cache Groups

[ocket8888]

This Bug Report affects these Traffic Control components:

• Traffic Ops

Current behavior:

A POST request to /api/Version/cachegroups/ID/queue_update will fail for any valid Version and ID with a request body that passes "action": "dequeue" along with a valid identifier for any existing CDN, with the error code being 500 Internal Server Error.

Example

POST /api/3.0/cachegroups/1/queue_update HTTP/1.1
User-Agent: python-requests/2.25.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Cookie: mojolicious=...
Content-Length: 33
Content-Type: application/json

{"action": "dequeue", "cdnId": 2}

HTTP/1.1 500 Internal Server Error
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: ...
Access-Control-Allow-Methods: ...
Access-Control-Allow-Origin: *
Content-Encoding: gzip
Content-Type: application/json
Permissions-Policy: interest-cohort=()
Set-Cookie: mojolicious=...;
Vary: Accept-Encoding
Whole-Content-Sha512: ...
X-Server-Name: traffic_ops_golang/
Date: Fri, 10 Jun 2022 16:44:21 GMT
Content-Length: 83

{
	"alerts": [
		{
			"text": "Internal Server Error",
			"level": "error"
		}
	]
}

Verified in API versions 2.0, 3.0, 3.1, and 4.0. The Type associated with the Cache Group does not appear to matter, nor does the number and/or Type(s) of cache servers it contains - or lack thereof.

Error from the TO logs:

ERROR: api.go:263: 2022-06-10T16:35:08.463504252Z: 172.23.0.1:40992 queueing updates: querying queue updates: pq: column "server_id" does not exist

Expected behavior:

This endpoint used to work, it should still work.

Steps to reproduce:

1. for any given, valid CDN ID, ID, and API Version:
   topost -fkpa API Version cachegroups/ID/queue_update '{"action": "dequeue", "cdnId": CDN ID}'

Workaround

Currently, individual servers may still be cleared of updates - note, however, that this must be done one-at-a-time, if using the Traffic Portal "Servers" table view it cannot be parallelized as TPv1 does not support bulk table row operations. As there is no limit to the number of servers that may be in a Cache Group and the API requires dequeuing a single server at a time, parallelizing this task via some scripting language could result in much greater network request load and/or a far longer operational time than if the /cachegroups/{{ID}}/queue_update endpoint could be used - although said impact has not been measured.