Add session_id support to wardrive client for capacity tracking

[Copilot]

The wardrive client now captures and includes session_id from the capacity check API in all MeshMapper posts to enable server-side session tracking and slot management.

Changes

• Capacity check flow: Capture session_id from capacitycheck.php response when allowed=true, store in state.wardriveSessionId
• API payload: Include session_id in all postToMeshMapperAPI() calls
• Validation: Fail-closed policy - disconnect if session_id missing at connect or before posting
• Cleanup: Clear session_id on disconnect in three locations (capacity release, event handler, timer cleanup)
• Debug logging: Track full lifecycle - receive, attach, clear
• Error handling: New disconnect reason "session_id_error" with terminal status message

Example

Capacity check response:

{
  "allowed": true,
  "session_id": "20251221-0019"
}

MeshMapper API post (with session_id):

{
  "key": "59C7754DABDF5C11CA5F5D8368F89",
  "lat": 45.42150,
  "lon": -75.69720,
  "who": "MrAlders0n",
  "power": "1.0w",
  "heard_repeats": "4e(11.5),b7(9.75)",
  "ver": "v1.4.1",
  "test": 0,
  "iata": "YOW",
  "session_id": "20251221-0019"
}

Error Behavior

Missing session_id triggers immediate error disconnect with terminal status: "Session ID error; try reconnecting"

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

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

---


## Requested Changes
Update the client to support a new session_id value returned by connectivitycheck.php during the connection “capacity check”.

Background

On connect, we call connectivitycheck.php with a payload like:

• key
• public_key
• who
• reason: "connect"

When the response returns allowed: true, the API now also returns a new field: session_id (e.g. "20251221-0019").

Requirements

1. Refresh session_id on every connect:

   • Every time the user initiates a connection, call connectivitycheck.php.
   • If the response returns allowed === true, treat the returned session_id as the authoritative value for the new connection and store it (overwriting any previously stored value).

2. Capture and persist session_id:

   • When connectivitycheck.php returns allowed === true, read session_id from the response.
   • Store it in a durable place (appropriate for the app/runtime) so it can be reused for subsequent API calls during that connection/session.
   • If allowed === false or session_id is missing, do not overwrite an existing valid stored value (unless explicitly intended).

3. Include session_id in all MeshMapper posts:

   • Modify postToMeshMapperAPI(...) so every request payload includes session_id.
   • The value must come from the stored session id (not a hard-coded constant).

4. Clear session_id on disconnect:

   • When the user disconnects, clear/unset the stored session_id so it is not reused on the next connection.
   • Ensure the next connection always fetches a fresh session_id via the capacity check.

5. Graceful behavior / fallbacks:

   • If there is no known session_id yet, either omit the field or send a safe default (confirm which behavior is preferred).
   • Add logging in debug mode showing when the session id is received, stored, cleared, and attached to outgoing posts (avoid logging full keys).

Example (desired payload shape)

const payload = {
  key: MESHMAPPER_API_KEY,
  lat,
  lon,
  who: getDeviceIdentifier(),
  power: getCurrentPowerSetting() || "N/A",
  heard_repeats: heardRepeats,
  ver: APP_VERSION,
  test: 0,
  iata: WARDIVE_IATA_CODE,
  session_id: getStoredWardriveSessionId() // newly added
};

Reference request/response

Capacity check request:

{
  "key": "59C7754DABDF5C11CA5F5D8368F89",
  "public_key": "8482e61880c65c134ba87444a8c2d506c87d47928f23fb7e13c76dc47fa1ff22",
  "who": "MrAlders0n",
  "reason": "connect"
}

Capacity check response:

{
  "allowed": true,
  "session_id": "20251221-0019"
}

---

💡 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.