[WIP] Fix race condition in ping operations

[Copilot]

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

Original prompt

Problem

When a manual ping is triggered during auto ping mode, the app can get stuck in a "Sending auto ping" state, repeatedly logging the same status message without actually sending pings or scheduling new ones.

Root Cause

There is a race condition in wardrive.js where the captured ping coordinates (state.capturedPingCoords) are shared between concurrent ping operations. When a manual ping overlaps with an auto ping's API post cycle:

1. Manual ping starts at time T and captures coordinates to state.capturedPingCoords
2. Manual ping's 7-second RX listening window begins
3. Auto ping timer fires (while manual ping is still processing)
4. Auto ping sends successfully and overwrites state.capturedPingCoords with its own coordinates
5. Manual ping's postApiAndRefreshMap completes and clears state.capturedPingCoords = null
6. Auto ping's RX window ends, but state.capturedPingCoords is now null
7. Auto ping logs "CRITICAL: No captured ping coordinates available for API post" and skips API post
8. Because API post is skipped, scheduleNextAutoPing() is never called
9. App gets stuck showing "Sending auto ping" indefinitely

Debug Log Evidence

From the console debug output:

[DEBUG] CRITICAL: No captured ping coordinates available for API post - this indicates a logic error
[DEBUG] Skipping API post to avoid posting incorrect coordinates
[DEBUG] Ping controls unlocked (pingInProgress=false) after skipping API post due to missing coordinates
[DEBUG] Status applied: "Sending auto ping"
[DEBUG] Status update (same message): "Sending auto ping"
[DEBUG] Status update (same message): "Sending auto ping"
... (repeats indefinitely)

Required Fix

Fix 1: Capture coordinates locally in setTimeout closure

Around line 1904 in wardrive.js, the coordinates should be captured in a local variable BEFORE the setTimeout call, rather than relying on shared state inside the timeout callback:

// BEFORE calling setTimeout, capture the coordinates in a local variable
const capturedCoords = state.capturedPingCoords; // Capture immediately

state.meshMapperTimer = setTimeout(async () => {
  // ... existing code ...
  
  // Use the locally captured coordinates (not the shared state)
  if (capturedCoords) {
    const { lat: apiLat, lon: apiLon, accuracy: apiAccuracy } = capturedCoords;
    // ... rest of API post logic
  }
  
  // DON'T clear state.capturedPingCoords here - each ping manages its own local copy
}, RX_LOG_LISTEN_WINDOW_MS);

Fix 2: Add fallback scheduling after error path

When the API post is skipped due to missing coordinates, scheduleNextAutoPing() is never called because it normally happens inside postApiAndRefreshMap. Add a fallback after the error handling:

// After the CRITICAL error handling block:
if (state.running && !state.autoTimerId) {
  debugLog("Scheduling next auto ping after skipped API post");
  scheduleNextAutoPing();
}

Files to Modify

• content/wardrive.js - The sendPing function's setTimeout callback (around lines 1904-1943)

Expected Behavior After Fix

• Each ping operation captures its own coordinates locally and is not affected by concurrent ping operations
• If an API post is skipped for any reason during auto mode, a new auto ping is still scheduled
• The app never gets stuck in "Sending auto ping" state

This pull request was created from Copilot chat.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.