Freika/dawarich · warning

[Settings] Failed to check recalculation status:

Error message

[Settings] Failed to check recalculation status:

What it means

The status poll fetched /api/v1/settings/transportation_recalculation_status with a Bearer API key and received a non-2xx response. The handler logs the HTTP status and returns early, leaving the recalculation progress UI showing stale state. Network-level failures are handled separately by the outer catch, which logs 'Error checking recalculation status'.

Source

Thrown at app/javascript/controllers/maps/maplibre/settings_manager.js:485

      if (!apiKey) {
        console.warn(
          "[Settings] No API key available for recalculation status check",
        )
        return
      }

      const response = await fetch(
        "/api/v1/settings/transportation_recalculation_status",
        {
          headers: {
            Authorization: `Bearer ${apiKey}`,
            "Content-Type": "application/json",
          },
        },
      )

      if (!response.ok) {
        console.warn(
          "[Settings] Failed to check recalculation status:",
          response.status,
        )
        return
      }

      const data = await response.json()
      this.updateRecalculationUI(data)
    } catch (error) {
      console.error("[Settings] Error checking recalculation status:", error)
    }
  }

  /**
   * Update UI based on recalculation status
   */
  updateRecalculationUI(status) {
    const controller = this.controller

View on GitHub (pinned to 97fad417c5)

Solutions

  1. Match the logged status: 401 → regenerate/re-enter the API key and reload; 404 → update the Dawarich backend to a version with the endpoint; 429 → slow the poll interval; 5xx → check server logs
  2. Verify the key directly: curl -H 'Authorization: Bearer <key>' .../api/v1/settings/transportation_recalculation_status
  3. Align frontend and backend versions after partial upgrades
  4. Back off polling on repeated failures instead of hammering the endpoint

Example fix

// before
if (!response.ok) {
  console.warn("[Settings] Failed to check recalculation status:", response.status)
  return
}
// after
if (!response.ok) {
  if (response.status === 401) {
    this.updateRecalculationUI({ status: "unauthorized" })
    return // key revoked — stop polling until reload
  }
  console.warn("[Settings] Failed to check recalculation status:", response.status)
  this.pollIntervalMs = Math.min(this.pollIntervalMs * 2, 60000)
  return
}
Defensive patterns

Strategy: validation

Validate before calling

if (!apiKey) { this.updateRecalculationUI({ status: "unknown" }); return }
const probe = await fetch("/api/v1/health", {
  headers: { Authorization: `Bearer ${apiKey}` },
})
if (probe.status === 401) { showReauthPrompt(); return }

Try / catch

try {
  const response = await fetch(url, { headers })
  if (response.status === 401) return // key revoked: stop polling, prompt re-auth
  if (!response.ok) { console.warn("[Settings] Failed to check recalculation status:", response.status); backOff(); return }
  this.updateRecalculationUI(await response.json())
} catch (error) {
  console.error("[Settings] Error checking recalculation status:", error)
}

Prevention

When it happens

Trigger: 401 when the API key is invalid, revoked, or belongs to a deleted user; 404 on an older backend build that predates the endpoint; 429 rate limiting from the poll cadence; 500 when the recalculation state store errors; gateway 502/504 during deploys.

Common situations: Regenerating the API key in settings while a map tab stays open with the old key; upgrading the frontend ahead of the backend so the endpoint is missing; self-hosted instances behind rate-limiting proxies; server errors during heavy recalculation jobs.

Related errors


AI-assisted analysis of Freika/dawarich@97fad417c5 (2026-08-21). Data as JSON: /api/errors/a41f40b5b8a008a9. Report an issue: GitHub.