Adding multithreading to the application

README.md

@@ -72,15 +72,23 @@ guessed): a shipment's `shipment_number` and `external_shipment_id`
 both hold the ticket number directly (e.g. both were `"AR-160269"`).
 "Pull Tracking Numbers":
 
-1. Fetches today's labels via `GET /v2/labels` - which gives
-   `tracking_number` and, importantly, `is_return_label` directly, so
-   telling a return label apart from an outgoing one needs no guessing.
-2. Looks up each label's shipment (`GET /v2/shipments/{id}`) to read
+1. Bulk-fetches **all** of today's labels and all shipments from the
+   last `SHIPSTATION_LOOKBACK_DAYS` (a code constant in
+   `shipstation_service.py`, default 7 days - wide enough to catch a
+   shipment that sat "pending" for a day or two before its label was
+   generated). This replaced an earlier version that looked up each
+   shipment individually (one HTTP call per ticket) - the actual cause
+   of the slowness, now down to a handful of bulk list calls.
+2. Fetches those (and any additional pages either needs) **concurrently**
+   via a PyQt `QThreadPool` - several requests in flight at once instead
+   of one after another. Capped at `MAX_CONCURRENT_REQUESTS` (default 5)
+   to stay well clear of any ShipStation rate limit.
+3. Only after both full batches have landed does it sort/correlate
+   labels to shipments to ticket numbers, entirely in memory - reading
+   `tracking_number` and `is_return_label` straight off each label, and
    the ticket number off `shipment_number` (checked first) or
    `external_shipment_id`, falling back to scanning the whole payload
    with `TICKET_NUMBER_REGEX` if neither is present.
-3. Groups tracking numbers by ticket number and merges them onto the
-   matching JIRA row.
 
 If a label's ticket number doesn't match any ticket you have locally
 (e.g. JIRA hasn't been imported yet, or it's an account outlier),