tcfdev opened a new issue, #7252: URL: https://github.com/apache/trafficcontrol/issues/7252
<!-- ************ STOP!! ************ If this issue identifies a security vulnerability, DO NOT submit it! Instead, contact the Apache Traffic Control Security Team at [email protected] and follow the guidelines at https://apache.org/security regarding vulnerability disclosure. - For *SUPPORT QUESTIONS*, use the #traffic-control channel on the ASF slack (https://s.apache.org/tc-slack-request) or the Traffic Control Users mailing list (send an email to [email protected] to subscribe). - Before submitting, please **SEARCH GITHUB** for a similar issue or PR * https://github.com/apache/trafficcontrol/issues * https://github.com/apache/trafficcontrol/pulls --> <!-- Do not submit security vulnerabilities or support requests here - see above --> ## This Bug Report affects these Traffic Control components: <!-- delete all those that don't apply --> - Traffic Ops - Traffic Router ## Current behavior: <!-- Describe how the bug happens --> Traffic Ops queries the Traffic Router endpoint `crs/stats` to parse / process / display information. The struct is expecting the `czCount` field to be a _uint64_ however in at least one instance the value returned was negative (implying an Integer Overflow in TR). From the TO error log: ``` ERROR: api.go:263: <id addr> decoding stats from CDN <CDN name> <traffic router>: json: cannot unmarshal number -2054406724 into Go struct field CRSStatsStat.stats.HTTPMap.czCount of type uint64 ``` Looking into the response from TR, one of the routers reported: ``` "server": { "czCount": -2055404181, <--- The culprit "geoCount": 26857914, "deepCzCount": 0, "missCount": 1498, "dsrCount": 0, "errCount": 0, "staticRouteCount": 0, "fedCount": 0, "regionalDeniedCount": 0, "regionalAlternateCount": 0 }, ``` ## Expected behavior: <!-- Describe what the behavior would be without the bug --> The `czCount` field should certainly _not_ be negative to prevent the bug from happening. However there may a bigger question in terms of "What to do when we've hit the max allowable value of a uint64? Is resetting the values considered appropriate?" ## Steps to reproduce: <!-- If the current behavior is a bug, please provide the *STEPS TO REPRODUCE* and include the applicable TC version. --> Whew uhh. Hit an endpoint more than 2 147 483 647 times to see if it rolls over (since Java doesn't have unsigned integer types). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
