US routing intermittently fails with connection_failed; raise travel time/distance thresholds to max

[sfc-gh-obielov]

Triage note (2026-04-23): RE-SCOPED to align with #54.

The original proposal ("set every routing threshold to its maximum allowed value for the US region, and ideally all regions") conflicts with #54's design philosophy of validated, opt-in safe defaults. Shipping max thresholds as the default exposes every deployment to DoS-shaped misuse and silent pathological routes.

New scope: implement this as a named preset continental in the #54 annotated-template system. Users who need cross-state or cross-country routing opt in by selecting the continental preset (or a region-specific variant like continental-usa). Default regions continue to use the safe standard preset.

Layering note (relates to #51): #51's Snowflake-side request-size guardrails must read their limits from the active ORS config so that when a user opts into continental, the guardrails widen automatically. Otherwise guardrails would reject calls the ORS server would accept — confusing and inconsistent. Single source of truth: the active ors-config.yml preset.

Revised acceptance criteria:

• A continental preset exists in the [Idea] Ship validated, annotated ors-config.yml templates #54 template set with the max-value threshold profile originally listed below.
• Region provisioner accepts a preset name; defaults to standard; continental is opt-in.
• US long-distance routes succeed when the US region is provisioned with the continental preset.
• [Idea] Add request-size guardrails for Matrix, Isochrones, Directions #51's guardrails read limits from the active preset (no hardcoded caps on the Snowflake side).
• Documented in build-routing-solution and routing-customization references.

This ticket is blocked on #54 landing the template system. The workaround in the original body (RESUME_ALL_SERVICES, ORS_STATUS, SETUP_CITY_ORS) remains valid until then.

---

Problem

When calculating routes in the US region, requests intermittently fail with a connection_failed error from the ORS service function.

Example response

[
  {
    "RESPONSE": "{\n  \"error\": \"connection_failed\",\n  \"message\": \"Cannot connect to ORS (host: ors-service-unitedstatesofamerica). Region may not be provisioned or service is suspended. Try: 1) CALL CORE.RESUME_ALL_SERVICES() to resume, 2) SELECT CORE.ORS_STATUS(region) to check readiness, 3) CALL CORE.SETUP_CITY_ORS(region) to provision a new region.\",\n  \"ors_host\": \"ors-service-unitedstatesofamerica\"\n}",
    "GEOJSON": null,
    "DISTANCE": null,
    "DURATION": null
  }
]

The ORS service for ors-service-unitedstatesofamerica appears to be reachable some of the time but drops connections on longer or larger-area US routes, suggesting that the configured routing thresholds (max travel time / max route distance) are too low for the continental US coverage area.

Proposed Fix

Set all routing thresholds for travel time and distance to the maximum allowed values in the ORS configuration for the US region (and ideally all regions), so that long cross-state routes don't get rejected or time out at the ORS layer.

Specifically, in the ORS ors-config.yml / profile configuration:

• maximum_distance → max allowed value
• maximum_distance_dynamic_weights → max allowed value
• maximum_distance_avoid_areas → max allowed value
• maximum_distance_alternative_routes → max allowed value
• maximum_distance_round_trip_routes → max allowed value
• maximum_waypoints → max allowed value
• maximum_visited_nodes → max allowed value
• maximum_snapping_radius → max allowed value
• Any maximum_search_radius / travel-time equivalents for isochrones and matrix endpoints

Apply to all routing profiles (driving-car, driving-hgv, cycling-*, foot-*, etc.) for the US deployment, and rebuild/redeploy the ORS service image.

Acceptance Criteria

• US long-distance route requests (e.g., cross-state) no longer fail with connection_failed due to threshold limits
• All travel time and distance thresholds in ORS config are set to maximum values
• Config change is documented in build-routing-solution skill references
• ors-service-unitedstatesofamerica health check remains green after redeploy

Workaround

Per the error message:

1. CALL CORE.RESUME_ALL_SERVICES() to resume suspended services
2. SELECT CORE.ORS_STATUS('unitedstatesofamerica') to check readiness
3. CALL CORE.SETUP_CITY_ORS('unitedstatesofamerica') to re-provision the region

[sfc-gh-obielov]

Addressed in PR #120 (commits e90f211 + 385a7c4).

Implementation:

• Per-host circuit breaker + retry/backoff in routing_service.py survives transient connection_failed blips that previously surfaced as user-facing errors.
• ## Sizing section in build-routing-solution/SKILL.md documents required RAM / -Xmx / graphs_data_access: MMAP for USA-scale extracts so the graph isn't built on an under-provisioned pool.
• VALIDATE_REGION_PREFLIGHT() warns at provision time when the pool is too small for the selected PBF — the most common root cause of intermittent USA failures.

Audit follow-up applied:

• Replaced weak deterministic jitter with random.uniform(0.75, 1.25) so simultaneous retries don't synchronize and re-trigger the failure.