Cap installation-hierarchy retries by a max_wait deadline

[martijnversluis]

De pairing-flow via Connections::Zaptec#connect! in StekkerWeb roept get_installation_hierarchy aan. Zaptec antwoordt bij een net-aangemaakte installatie soms met 204 No Content totdat de provisioning klaar is. De client retryde nu 1× met 2 s pauze en gaf daarna op — voor sommige installaties te vroeg.

Achtergrond

Sentry-issue https://sentry2.stekker.app/organizations/sentry/issues/2101/ ving één gebruiker die pairing niet kon afronden. Uit de outbound logs:

• 18:01:47 → 204
• 18:01:49 → 204 (retry) → RequestFailed naar de user
• 18:01:55 → 200 (Zaptec is nu klaar, 6 s later)

De gebruiker klikte 4× de wizard opnieuw, gaf toen op, gooide het charge_point en de site weg en begon van nul. Na ~22 minuten was er een nieuwe site + nieuw charge_point met connected_at gezet. Onnodige moeite die met een langere backoff niet nodig was geweest.

Wat er verandert

get_installation_hierarchy accepteert nu een max_wait: kwarg. Exponentiële backoff verdubbelt vanaf 2 s; zodra de cumulatieve wachttijd max_wait zou overschrijden, wordt de laatste sleep zo gecapt dat de laatste poging op precies max_wait seconden gebeurt.

client.get_installation_hierarchy(id)                       # default 30.seconds
client.get_installation_hierarchy(id, max_wait: 50.seconds) # pogingen op t=0,2,4,8,16,32,50
client.get_installation_hierarchy(id, max_wait: 5.seconds)  # pogingen op t=0,2,4,5
client.get_installation_hierarchy(id, max_wait: 0)          # één poging, geen retries

Een ActiveSupport::Duration (zoals 30.seconds) of een integer aantal seconden zijn beide geldig.

Default

DEFAULT_HIERARCHY_MAX_WAIT = 30.seconds — pogingen op cumulatief t=0, 2, 4, 8, 16, 30 (6 pogingen totaal). Dat vangt de meeste provisioning-vertragingen op zonder de user langer dan een halve minuut op een spinner te laten wachten.

Consumenten die per aanroep willen tunen: batchjobs (bv. refresh_grants_for in StekkerWeb) kunnen max_wait: 0 doorgeven zodat een enkele 204 gewoon wordt overgeslagen; user-facing pairing zou eventueel juist max_wait: 60.seconds kunnen zetten.

Test-strategie

• Bestaande happy-path spec ongewijzigd.
• Retry-happy-path (2× 204 → 200) met assertion op de exacte sleep-sequence.
• max_wait: 50 all-204 loopt tot deadline (pogingen op t=0,2,4,8,16,32,50, dus sleeps 2,2,4,8,16,18, WebMock times(7)).
• Cap-test met max_wait: 5 (pogingen op t=0,2,4,5, dus sleeps 2,2,1).
• ActiveSupport::Duration (5.seconds) werkt identiek aan integer 5.
• max_wait: 0 doet één poging zonder sleep.

Version bump naar 1.4.0 (nieuwe kwarg, backwards-compatible via default).