[BUG] Server history gives up after startup upstream resolution miss

[CaneTLOTW]

Follow-up discovered during Issue #52 read-only audit on exact runtime/develop SHA 4b00b81e3f85c012504ea99b8b50f02d742d378e.

Observed live store state after successful HA restart:

server_history_ready=false
server_history_source=local_fallback
server_history_reason=upstream_vehicle_unavailable
last_sync=2026-09-02T19:59:43Z

This means PR #51's historical /trips transport is present but the current runtime never reached it because ServerHistoryManager._resolve_upstream() did not resolve a client/vehicle during initialization.

Current lifecycle is fragile:

• async_setup_entry() starts server_history.async_initialize() immediately in the background;
• async_initialize() resolves the upstream client/vehicle and, on failure, schedules only three retries;
• _retry_initialize() sleeps 5 seconds, so the manager gives up after a short startup window;
• after those retries there is no later reacquisition/resync trigger when Stellantis Vehicles becomes fully available.

Current resolution path also depends first on the selected HA device's config_entries relation and only then checks that entry's runtime_data / legacy cache. The upstream's current supported runtime contract is ConfigEntry.runtime_data = StellantisVehicles, with per-VIN coordinators stored on that object.

Required investigation/fix:

1. On the live runtime, determine exactly which resolution step fails after restart: selected device reference, device config_entries, upstream config entry lookup, runtime_data, async_get_coordinator_by_vin(vin), or cached _vehicle VIN match.
2. Keep VIN verification strict. Never bind to a different vehicle merely because only one upstream entry exists.
3. Make upstream resolution resilient to startup ordering. A missed initial lookup must not permanently disable server history for the whole HA uptime.
4. Prefer a narrow local solution in sv_dashboard; do not modify or monkey-patch andreadegiovine/homeassistant-stellantis-vehicles.
5. A safe fallback may scan loaded stellantis_vehicles config entries when the device-registry link is absent/stale, but only accept an entry whose already-cached coordinator/vehicle matches the exact configured VIN.
6. Add a cancellable delayed/background reacquisition strategy (or equivalent event-driven retry) so upstream_vehicle_unavailable can recover later without blocking HA startup or creating an unbounded tight loop.
7. Once resolution succeeds, run the normal historical sync and canonical rebuild, update readiness/source truthfully, and refresh entities.
8. Preserve local fallback while unresolved and preserve archived server rows; do not mark them fresh until a successful sync.
9. Add regression tests for startup-order miss → later recovery, stale/missing device-registry config-entry linkage, strict VIN mismatch rejection, cancellation/unload, and no duplicate concurrent sync loops.

This issue should be solved before relying on Issue #52's historical server-row backfill in the UI, because while server_history_ready=false the Trip History card intentionally uses its Recorder/local fallback path.

No main promotion or release until runtime validation on an exact merged develop SHA.

[CaneTLOTW]

ChatGPT → Codex Handoff

Repository: CaneTLOTW/sv_dashboard

Base SHA: 4b00b81e3f85c012504ea99b8b50f02d742d378e

Work branch already exists: fix/server-history-upstream-reacquire

Task: Fix Issue #53 in sv_dashboard only. Do not modify or patch the Stellantis Vehicles upstream repository.

First: prove the live failure point

Before changing source, inspect the currently installed HA runtime and report which exact lookup step fails after restart:

1. configured SV VIN;
2. selected HA device exists;
3. selected device config_entries contains the Stellantis Vehicles config entry;
4. that upstream config entry is loaded and exposes runtime_data;
5. runtime_data.async_get_coordinator_by_vin(vin) returns a coordinator;
6. coordinator/client cached vehicle data contains the exact same VIN.

Do not issue any extra Stellantis network call merely to discover the vehicle. This resolution must use already-loaded/cached upstream runtime objects only.

Implement resilient resolution

After identifying the failure, make the smallest robust fix with these constraints:

• strict VIN match is mandatory;
• prefer the current device-linked upstream entry path;
• if the device linkage is absent/stale, allow a fallback scan across loaded stellantis_vehicles config entries and accept only an entry whose cached coordinator/vehicle matches the exact VIN;
• preserve support for current ConfigEntry.runtime_data and the existing legacy cache compatibility path;
• no monkey-patching and no new OAuth/session stack.

Lifecycle/retry requirement

The current 3 × 5 s retry window is not sufficient. A transient startup-order miss must recover later in the same HA uptime.

Implement one cancellable background reacquisition mechanism that:

• does not block HA startup;
• cannot spin in a tight loop;
• prevents duplicate concurrent history-sync/retry loops;
• is cancelled cleanly on SV config-entry unload;
• once upstream resolution succeeds, runs the normal historical /trips sync/canonical rebuild and refreshes registered history entities;
• preserves local_fallback and archived rows while unresolved;
• marks server_history_ready=true/source=server only after successful sync.

A bounded/exponential retry with a sensible maximum interval is acceptable if simpler than event-driven wiring, provided it keeps trying after the initial 15 seconds and is unload-safe.

Regression tests

Add tests for at least:

1. normal device-linked runtime_data resolution;
2. stale/missing device link recovered by scanning loaded upstream entries with exact VIN;
3. wrong-VIN upstream entry rejected;
4. initial miss followed by later cached upstream availability transitions to successful sync;
5. no duplicate concurrent retry/sync loops;
6. retry task cancellation on unload/shutdown;
7. existing local fallback/archive remains intact during unresolved state.

Run the full repository validation from AGENTS.md, open a PR to develop, and report back here under ## Codex → ChatGPT Ergebnis with live failure point, changed files, exact HEAD, tests, CI and PR number.

Do not merge, release, deploy to HA or touch main.

[CaneTLOTW]

Codex → ChatGPT Ergebnis

Result

SERVER_HISTORY_UPSTREAM_REACQUIRE_FIX=IMPLEMENTED

Live failure point

• The selected SV Dashboard config entry contains its stable vehicle identity and selected HA device.
• The device registry points to the loaded Stellantis Vehicles config entry as the primary upstream entry.
• The server-history store is still in the preserved local fallback state: server_history_ready=false, server_history_source=local_fallback, server_history_reason=upstream_vehicle_unavailable.
• The previous source resolved only device-linked upstream entries and stopped after three 5-second retries. It therefore had no later reacquisition path when the upstream runtime/cache became available after startup ordering.
• The source/runtime inspection was read-only; no HA store, config entry, entity registry, token, or upstream state was changed.

Implemented on branch

• Branch: fix/server-history-upstream-reacquire
• Base: 4b00b81e3f85c012504ea99b8b50f02d742d378e
• Commit: 97f78775b177003fb5f858779a00b31d0a810372
• PR: fix: reacquire server history upstream after startup miss #54, target develop, open

Changed files:

• custom_components/sv_dashboard/server_history.py
• custom_components/sv_dashboard/upstream_compat.py
• custom_components/sv_dashboard/__init__.py
• tests/upstream_vehicle_resolution_test.py
• tests/server-history-reacquire.test.mjs
• CHANGELOG.md

Behavior is limited to loaded runtime/legacy caches and exact VIN matching. The device-linked path remains preferred; a stale or missing device link can fall back to loaded upstream ConfigEntries only. Reacquisition is one cancellable worker with bounded backoff, no tight loop and no network discovery. Successful resolution reuses the normal history sync, readiness and entity-refresh path; local fallback/archive data remains in place until then.

Validation

• Python compilation: PASS
• JavaScript syntax checks: PASS
• JSON checks: PASS
• Resolver self-test: PASS
• Server-history transport self-test: PASS
• Node suite: 144 PASS
• GitHub Validate run 34855893814: Source/frontend PASS, HACS PASS, Hassfest PASS
• Earlier concurrent Validate run 34855871004: Source/frontend PASS, HACS PASS, Hassfest PASS
• Working tree: clean

NO_HA_RUNTIME_MUTATION=YES

NO_MERGE=YES

NO_RELEASE=YES

NO_DEPLOYMENT=YES

[CaneTLOTW]

ChatGPT → Codex Handoff

Repository: CaneTLOTW/sv_dashboard

Task: Revise existing PR #54 in place. Do not open a new PR.

Current head reviewed: 97f78775b177003fb5f858779a00b31d0a810372.

Blocking lifecycle defect found during review:

• async_unload_entry() currently calls server_history.async_cancel_background_tasks() before async_unload_platforms(...) has confirmed unload success.
• If platform unload returns False, the config entry remains loaded, but _shutdown_requested=True and the reacquisition task has already been cancelled, so server-history recovery can never resume during that HA uptime.

Required fix:

1. cancel reacquisition/background tasks only after a confirmed successful unload, or remove the explicit pre-unload cancellation and rely on the already-registered entry.async_on_unload(server_history.async_cancel_background_tasks) callback;
2. keep cancellation idempotent and preserve the existing successful-unload behavior;
3. add a regression test proving a failed platform unload does not permanently shut down the reacquisition worker/state;
4. keep all other [BUG] Server history gives up after startup upstream resolution miss #53 behavior unchanged: exact VIN matching, loaded-cache-only fallback scan, one bounded-backoff worker, no upstream modifications, no extra network discovery.

Run the full validation suite and update PR #54. Report back here with the new exact HEAD and CI result.

Do not merge, release or deploy.

[CaneTLOTW]

Codex → ChatGPT Ergebnis

PR #54 wurde in place revidiert.

• Neuer HEAD: 0564f4ae33d04d3ce275bf11e2a42de3e3c10b09
• Branch: fix/server-history-upstream-reacquire
• PR: fix: reacquire server history upstream after startup miss #54 nach develop, weiterhin offen

Review-Fix:

• async_unload_entry() beendet die Server-History-Reacquisition erst nach bestätigtem erfolgreichem Platform-Unload.
• Bei unloaded == False bleibt der Worker-/Runtime-Zustand unverändert und kann während derselben HA-Laufzeit weiterarbeiten.
• Kündigung bleibt idempotent; der bestehende erfolgreiche Unload-Pfad bleibt erhalten.
• Neuer Regressionstest deckt den fehlgeschlagenen Unload ab.

Validierung:

• Python-Kompilierung: PASS
• JavaScript-Syntaxchecks: PASS
• JSON-Checks: PASS
• Resolver-/Transport-Selbsttests: PASS
• Vollständige Node-Suite: 145 PASS
• GitHub Validate für den neuen HEAD: Source/Frontend PASS, HACS PASS, Hassfest PASS
• HACS-Rerun war nach einem transienten parallelen manifest=None-Fehler ebenfalls PASS.
• Arbeitsbaum sauber

NO_MERGE=YES

NO_RELEASE=YES

NO_DEPLOYMENT=YES

[CaneTLOTW]

ChatGPT review / merge result

PR #54 has been re-reviewed at head 0564f4ae33d04d3ce275bf11e2a42de3e3c10b09.

The prior lifecycle defect is fixed: async_cancel_background_tasks() is now called only inside the successful if unloaded: branch, so a failed async_unload_platforms() no longer permanently disables reacquisition for the still-loaded config entry. The regression test covers that ordering. The previous review thread is resolved.

PR #54 was merged to develop.

• Merge SHA / current develop: 3f458b3906ce2c1db13ea982f2488418978ef0d3
• Post-merge Validate run 34859013574: Source/frontend PASS, HACS PASS, Hassfest PASS
• main unchanged
• no release yet

Issue #53 stays open until live HA validation proves that a startup-order miss now recovers and performs a real historical sync.

ChatGPT → Codex Handoff

Repository: CaneTLOTW/sv_dashboard

Task: Runtime-validate exact merged develop SHA 3f458b3906ce2c1db13ea982f2488418978ef0d3 on the owner's HA installation.

1. Back up the currently installed custom_components/sv_dashboard first.
2. Install exactly SHA 3f458b3906ce2c1db13ea982f2488418978ef0d3; do not use moving develop without SHA verification.
3. Restart Home Assistant and verify Core/SV startup PASS.
4. Observe server-history state for long enough to cover at least the initial reacquisition window. Record transitions of:
   • server_history_ready
   • server_history_source
   • server_history_reason
   • last_sync
5. Required success condition: current loaded Stellantis runtime is resolved with the exact configured VIN and the normal historical /trips sync runs, ending in server_history_ready=true, server_history_source=server, server_history_reason=sync_succeeded, with a fresh last_sync.
6. Confirm no duplicate retry workers / repeated tight-loop warnings and no wrong-VIN binding.
7. Confirm Trip History still renders and archived/local data remain intact during any transient unresolved period.
8. Do not modify dashboard/entity/config state other than installing this exact source and restarting HA. No release/main promotion.

Report under ## Codex → ChatGPT Ergebnis with exact installed SHA, backup path, restart result, observed readiness transition/timing, final status metadata, relevant errors/warnings, and whether rollback was needed.

[CaneTLOTW]

Codex → ChatGPT Ergebnis

Runtime validation

• Requested SHA: 3f458b3906ce2c1db13ea982f2488418978ef0d3
• Exact SHA was fetched and installed byte-identically (62/62 tracked files).
• Pre-install backup: /share/sv_dashboard_backups/20260914T170000Z-pre-runtime-3f458b3/sv_dashboard
• Installed version during validation: 0.6.0-beta.13
• Home Assistant restart after install: completed; the connector returned a timeout, but Core came back and ha-readonly core check passed.

Observed history state

The config entry remained loaded and the preserved history store remained available. During the initial post-start attempt, the state was:

server_history_ready=false
server_history_source=local_fallback
server_history_reason=upstream_vehicle_unavailable
last_sync=2026-09-02T19:59:43.758197+00:00

The later bounded reacquisition attempt ran, but the upstream client failed with:

Connector is closed.

The resulting state was:

server_history_ready=false
server_history_source=local_fallback
server_history_reason=sync_failed
server_history_capability=authenticated_trips_transport
last_sync=2026-09-02T19:59:43.758197+00:00
server_history_error=Connector is closed.

No duplicate-worker or tight-loop warning was observed. The persisted local/archive data remained intact (server_trips_raw=122, canonical_trips=122, charges=25). No wrong-VIN binding or extra discovery call was performed.

Rollback

Because the required transition to server_history_ready=true, source=server, reason=sync_succeeded with a fresh last_sync did not occur, the exact candidate was rolled back once to the backed-up beta.13 installation. Home Assistant was restarted again; final ha-readonly core check is PASS and installed version is 0.6.0-beta.13. No HA store, dashboard, entity registry or configuration was manually changed.

RUNTIME_VALIDATION=FAIL
UPSTREAM_RUNTIME_RESOLUTION=FAIL_CONNECTOR_CLOSED
SERVER_HISTORY_SYNC=NOT_CONFIRMED
ROLLBACK=PASS
NO_MERGE=YES
NO_RELEASE=YES
NO_DEPLOYMENT=YES

[CaneTLOTW]

Runtime review

The merged develop candidate 3f458b3906ce2c1db13ea982f2488418978ef0d3 did not satisfy the #53 acceptance gate. Reacquisition progressed past upstream_vehicle_unavailable, but the authenticated history request failed with Connector is closed., leaving server_history_ready=false, source=local_fallback, reason=sync_failed; archive/local rows were preserved and the HA test was rolled back successfully.

This means the resolver/reacquisition work is useful but #53 is not complete at runtime. The remaining transport-lifecycle blocker is tracked separately in #55 so the root cause can be audited without mixing it with the already-merged resolver change.

Keep #53 open until #55 is fixed and a fresh exact-develop runtime acceptance reaches:

server_history_ready=true
server_history_source=server
server_history_reason=sync_succeeded
last_sync=<fresh>

No release/main promotion meanwhile.