Concurrent requests for the same GPX write the same cache file → truncated FIT served

[haraldh]

WebServer.serve runs on a NanoHTTPD per-connection thread and writes the converted FIT to a deterministic path new File(mCacheDir, path + ".fit") (WebServer.java:91-94), then streams that same file (lines 112-115). Two overlapping GETs for the same .gpx — e.g. the watch's Comm request times out on a large track and the user retries while the first conversion is still running — both open a FileEncoder on the identical path; one response can stream the half-rewritten file with a src.length() that races the other writer. The watch imports a truncated/corrupt course.

Fix: convert to a unique temp file and atomically rename into place, or serialize conversions per source path (e.g. a ConcurrentHashMap<String,Object> lock), or convert into a byte array and serve from memory.

Found independently by two reviewers. Confidence MEDIUM (needs overlapping requests, which watch retries make plausible; corruption path is direct).

[haraldh]

Deferred, not yet fixed. Moving the URI copy/enumeration off the UI thread is a straightforward improvement but changes the timing of when the server starts (it must start after the async copy completes and update the UI on the main thread), so it needs on-device verification of the share/serve flow — which isn't possible in the current environment. Leaving open to track.