[AkshayShah03]

Description

Issue: inet.Connection.Wakeup returns success while the vehicle is still asleep. When wake_up answers 200 with "state": "asleep", err is nil, so protocol.Temporary(err) is false and the function returns after one request. The 10 second poll loop never runs.

Fix: send one wake_up (resent only if the request fails), then poll the unbilled GET api/1/vehicles/{vin} endpoint every second until the vehicle reports online. If the context expires first, return the new ErrWakeupPending, which wraps the context error.

Tests:

• TestWakeupPollsVehicleStateUntilOnline
• TestWakeupResendsFailedWakeRequest
• TestWakeupPendingWhenContextExpires

All three fail on main. go test -race ./... passes.

Type of change

• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Bug fix (non-breaking change which fixes an issue)
• Documentation update

Checklist:

• My code follows the style of this project.
• I have performed a self-review of my code.
• I have made corresponding updates to the documentation.
• I have added/updated unit tests to cover my changes.

[sethterashima]

This needs a fix but there are some issues here.

I believe the server will send a wake up to the car and then immediately reply with the car's current state (not necessarily online). If we poll here by sending more wake calls, then this could very easily hit API limits; wakes are their own billing category: https://developer.tesla.com/docs/fleet-api/billing-and-limits.

Additionally, some callers invoke this function with shorter timeouts than wakePollInterval.

A better approach would be to poll on the vehicle endpoint https://developer.tesla.com/docs/fleet-api/endpoints/vehicle-endpoints#vehicle, which is not billed but does report online status. Return an error if the vehicle doesn't go to online before the context expires. Probably a special error that indicates the car was sent the request but has not (yet) reponsed, which the caller might want to handle differently than other failures.

[AkshayShah03]

Thanks, that makes sense. I've reworked it in 297ba95:

• Wakeup sends a single wake_up (resent only if the request itself fails), then polls GET api/1/vehicles/{vin} until the state is online.
• The poll interval is now 1 second, so it works with short caller timeouts.
• If the context expires after the wake up was sent, it returns ErrWakeupPending, which wraps the context error. It's marked may-have-succeeded and temporary.

One question about the proxy: httpStatusCode maps unknown errors to 500, so a wake_up through tesla-http-proxy that doesn't finish within the proxy timeout (10s by default) now returns 500, where before it returned 200 right away. Would you like ErrWakeupPending mapped to 408, like ErrVehicleNotAwake, or something else? I can add it here or in a follow-up.