You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 33839ab
Browse filesBrowse the repository at this point in the historyBrowse files
release: EVABRPUploader 2.1.7 — keep the broadcast, and time the query
Two things the last log said, one of which contradicts the note that shipped with 2.1.6.
That release claimed the map service never bound. The log says map=bound: the binder is
alive and it is the query that comes back with nothing. Different failure, different fix,
and the claim was a guess dressed as a finding. The query is now timed and the elapsed
time goes in the log. It is bounded by a two-second wait inside EVHardware, so a null
returning immediately was refused or answered undecodably, and a null returning at the
bound is a service that did not answer in time. Nothing visible from outside the library
tells those apart, which is exactly how the wrong note got written.
The broadcast is real. The action is confirmed by the vendor-service work in EVHardware:
the weather app sends com.saicmotor.weather when it refreshes itself, on no schedule this
app can ask for. 2.1.6 listened and then forgot between refreshes — and the app restarts
every time the driver opens it to read the log, which is the worst possible moment to
begin waiting for one. The last reading now survives a restart for two hours, and the
platform is asked at start-up, and again on any upload still without a temperature, for a
broadcast it may already be holding. That costs nothing and answers at once if the weather
app sends its update sticky.
A reading now carries its age in the log as well as its place, because where a value came
from does not say whether it still describes the day.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
0 commit comments