OCPP: clean up charge point lifecycle between subtests

[andig]

Summary

The OCPP test suite shares a singleton CS server across subtests via ocpp.Instance(), and the drain goroutine started in startChargePoint for handler.triggerC was never stopped — every call leaked one goroutine for the lifetime of the test process. The triggerC channel was also only make(chan …, 1), so concurrent handler invocations spawned extra sender goroutines that piled up under CI CPU pressure.

This is the structural race that previous OCPP test/test-adjacent fixes did not address:

• 7a24dbd (OCPP: fix flaky test deadlock between trigger handler and WS read loop #29725) — OCPP: fix flaky test deadlock between trigger handler and WS read loop — switched defer triggerC <- … to go func() { triggerC <- … }() so handlers no longer block the WS read loop.
• e07838b (OCPP: dispatch RemoteStartTransaction asynchronously to avoid WebSocket deadlock #29838) — OCPP: dispatch RemoteStartTransaction asynchronously to avoid WebSocket deadlock — fixed a related deadlock in OnStatusNotification → RemoteStartTransactionRequest.

Both removed specific blocking sends inside handlers, but the leaked drain goroutines and the capacity-1 buffer remained — visible as the intermittent TestOcpp/TestAutoStart 10s timeout (followed by connection refused on TestConnect/TestTimeout) seen on otherwise unrelated PRs (e.g. #29861, plus recent Solax / Huawei EMMA branches).

This PR:

• Increases triggerC buffer from 1 to 16 — handlers dispatch via go func() { triggerC <- … }(), so a tight buffer just multiplies blocked-sender goroutines.
• Registers a t.Cleanup per startChargePoint that calls cp.Stop() (if still connected) and signals the drain goroutine to exit via a done channel.
• Uses a done channel rather than close(triggerC), because the handler senders would otherwise panic with send on closed channel.

Test plan

• go build ./charger/...
• go vet ./charger/
• go test -run TestOcpp -count=1 -timeout 60s ./charger/ — 5 separate invocations, all pass (~26 s each)

🤖 Generated with Claude Code

[sourcery-ai]

Hey - I've left some high level feedback:

• In the drain goroutine, consider using case msg, ok := <-handler.triggerC and returning when !ok so that a future change that closes triggerC doesn’t result in an infinite loop continuously reading the zero value from a closed channel.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In the drain goroutine, consider using `case msg, ok := <-handler.triggerC` and returning when `!ok` so that a future change that closes `triggerC` doesn’t result in an infinite loop continuously reading the zero value from a closed channel.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}