alficles commented on pull request #6017: URL: https://github.com/apache/trafficcontrol/pull/6017#issuecomment-879623520
@rob05c > It's actually all four. It's how long after data modifications are made, and an operator queues, and t3c runs, and t3c requests /update_status, and t3c determines that it needs to update, and t3c requests the data endpoint. Right, but "t3c runs, and t3c requests /update_status, and t3c determines that it needs to update, and t3c requests the data endpoint" is expected to be very fast, almost all at once. And given that most deployments have caches polling on an interval, it's very likely that even on fairly short timeframes, one of those will poll immediately after a queue. All of that is genuinely very likely, as @rawlinp said. The only part that is very unlikely is changes within a cache-time of a queue. That's unlikely... unless you are scripting, then it's nearly certain and you have a problem. Nevertheless, you've identified the correct way to fix the problem. As the PR stands, it has all the appropriate controls for an operator to handle the potential races, but it does have it on by default. It's fine to provide the feature, but thinking about how frustrated someone would be to be debugging this issue after upgrading, I think it should either be off by default in this PR or this PR should be updated with the information required for t3c to behave correctly, even in the corner cases. The default case shouldn't contain surprises, I think. -- 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]
