Fix ping controls unlocking prematurely before API post completes

[Copilot]

The "Send Ping" and "Start Auto Ping" buttons unlock during the "Finalizing heard repeats" phase, before API posting completes. This allows users to trigger overlapping pings, causing timer desync and state inconsistency.

Root Cause

The 7-second cooldown timer expires when RX listening completes, but API posting happens after with an additional 3+ second delay. Controls unlock too early.

Changes

• Added state.pingInProgress flag to track full ping lifecycle independently of cooldown timer
• Lock controls after validation passes in sendPing(), before mesh transmission
• Unlock controls only after API post completes in postApiAndRefreshMap(), or on error paths
• Created unlockPingControls(reason) helper to eliminate duplication across unlock paths
• Updated updateControlsForCooldown() to check both cooldown timer AND pingInProgress flag

Behavior

Controls now remain locked for entire sequence:

Ping sent → RX listening (7s) → Finalizing repeats → Posting to API (3s + API time) → Unlock

The existing cooldown timer continues to function as before; the new flag provides lifecycle-based locking on top of time-based cooldown.

Documentation

Updated CONNECTION_WORKFLOW.md to document control locking behavior during ping operations.

Original prompt

MeshCore GOME WarDriver - Development Guidelines

Overview

This document defines the coding standards and requirements for all changes to the MeshCore GOME WarDriver repository. AI agents and contributors must follow these guidelines for every modification.

---

Code Style & Standards

Debug Logging

• ALWAYS include debug console logging for significant operations
• Use the existing debug helper functions:
  • debugLog(message, ...args) - For general debug information
  • debugWarn(message, ... args) - For warning conditions
  • debugError(message, ... args) - For error conditions
• Debug logging is controlled by the DEBUG_ENABLED flag (URL parameter ? debug=true)
• Log at key points: function entry, API calls, state changes, errors, and decision branches

Status Messages

• ALWAYS update STATUS_MESSAGES.md when adding or modifying user-facing status messages
• Use the setStatus(message, color) function for all UI status updates
• Use appropriate STATUS_COLORS constants:
  • STATUS_COLORS.idle - Default/waiting state
  • STATUS_COLORS. success - Successful operations
  • STATUS_COLORS.warning - Warning conditions
  • STATUS_COLORS.error - Error states
  • STATUS_COLORS.info - Informational/in-progress states

---

Documentation Requirements

Code Comments

• Document complex logic with inline comments
• Use JSDoc-style comments for functions:
  • @param for parameters
  • @returns for return values
  • Brief description of purpose

docs/STATUS_MESSAGES.md Updates

When adding new status messages, include:

• The exact status message text
• When it appears (trigger condition)
• The status color used
• Any follow-up actions or states���

docs/CONNECTION_WORKFLOW.md Updates

When modifying connect or disconnect logic, you must:

• Read docs/CONNECTION_WORKFLOW.md before making the change (to understand current intended behavior).
• Update docs/CONNECTION_WORKFLOW.md so it remains accurate after the change:
  • Steps/sequence of the workflow
  • Any new states, retries, timeouts, or error handling
  • Any UI impacts (buttons, indicators, status messages)

---

Requested Change:

Issue: “Send Ping” and “Start Auto Ping” unlock too early, allowing desynced pings/timers

Summary

When a ping is initiated, the UI correctly locks the Send Ping and Start Auto Ping controls. However, they appear to unlock prematurely during the “Finalizing heard repeats” phase, before the ping workflow has fully completed.

Expected Behavior

The Send Ping and Start Auto Ping controls must remain locked for the entire ping lifecycle and should never unlock until Posting to API has fully completed (i.e., the API post finishes successfully or the flow terminates in a handled failure state).

Actual Behavior

The controls unlock at “Finalizing heard repeats”, even though the workflow has not finished posting to the API. This allows the user to start another ping while the prior ping is still completing.

Impact / Why This Matters

Because the controls unlock early, a user can trigger a second ping while the first is still in-flight, which can:

• Desync timers
• Cause inconsistent state between the UI and the underlying ping workflow
• Affect both Auto Ping and Manual Ping behavior (timing, sequencing, and reliability)

Requested Fix

Update the UI locking/unlocking logic so that:

• Lock begins immediately when a ping starts.
• Unlock occurs only after the Posting to API step is fully complete (or after an explicitly handled terminal failure state).
• Prevent any user action that can start a new ping while a previous ping is still posting/completing.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.