The longest field test to date produced the most data — and exposed the most serious performance bug I've encountered. The geolocation engine was emitting results for nearly five hours after the drive ended. Of 264 total pin drops, only 83 occurred during the actual drive; the remaining 181 drained out of a processing queue over the following four hours.
The root cause was a deduplication system that wasn't actually deduplicating. The engine's queue was supposed to collapse repeated observations from the same transmitter, but the code was looking for field names that didn't match the actual data format — a simple key mismatch that caused every observation to be treated as unique. With no deduplication, the queue grew without bound during active driving and then slowly drained after the drive ended.
I fixed the deduplication keys, added queue flushing when all clients disconnect, and implemented guards that stop processing when no one is listening for results. But the deeper problem was processing speed: the Bayesian grid search was taking approximately 25 seconds per observation, far too slow for real-time use during driving.
The solution was parallelization. I restructured the grid search to run across multiple CPU cores simultaneously, splitting the computation into independent worker processes that each evaluate a portion of the search grid. A new standalone worker module handles initialization of terrain data and road network indices in each process, avoiding the overhead of copying large datasets. The result: processing time dropped from 25 seconds to under 6 seconds per observation — fast enough to keep up with incoming data during a typical drive.
A pre-flight test confirmed the full pipeline working end-to-end: WebSocket connection, location update, RF observation ingestion, parallel grid search, and pin drop returned in 5.6 seconds at 74% confidence.