32f4ccdd48
The sync route asked Dell about every pending service tag in one request. bulk_lookup sends 100 tags per HTTP call at a 15 second timeout, so a freshly-onboarded site was dozens of sequential calls inside a single web request. A gunicorn worker timeout or a proxy would plausibly kill it first, leaving the user with a failure after minutes and no way to tell what landed. F3 released the pooled connection before the vendor call, which stopped one sync from taking the app down, but did not make the request itself survivable. Extract the sync into a service taking a per-run tag limit. The route now caps at 200 tags - two Dell calls - and returns how many are still pending so the caller can run it again. A flask warranty sync-dell command does the same work from the command line for a large first-run backfill. The chunk is sampled at random rather than taken off a stable order. A serial Dell does not recognize never gains a warranty and so stays pending forever; under a stable order those dead tags would occupy every chunk and the sync would never reach the rest of the fleet. Nothing runs this on a schedule. The operation is used a few times a year, so a cron would idle-poll the warranty tables tens of thousands of times a year for nothing and log a configuration failure on every run at sites without Dell credentials. The two existing sync tests patched get_provider on the route module; the provider is now resolved in the service, so they patch it there.
8.8 KiB
8.8 KiB