[Control Plane] Add unit tests for retry handler

[santoshkumarradha]

Summary

Add unit tests for the retry handler in the control plane. This is a small, self-contained file (36 lines) that handles retry logic for failed executions.

Current State

• File: control-plane/internal/handlers/retry.go
• Size: 36 lines
• Test coverage: None

What to Test

1. Successful retry submission
2. Invalid execution ID handling
3. Missing execution ID parameter
4. Error response format validation

Implementation Notes

• This handler has minimal external dependencies, making it ideal for unit testing
• Mock the execution store interface for isolated testing
• Test both success and error paths

Acceptance Criteria

• Create control-plane/internal/handlers/retry_test.go
• Test coverage for happy path (successful retry)
• Test coverage for error cases (invalid ID, missing ID)
• All tests pass with go test ./internal/handlers/...

Files

• Source: control-plane/internal/handlers/retry.go
• Test: control-plane/internal/handlers/retry_test.go (new)

---

Using AI to solve this issue? Read our AI-Assisted Contributions guide for testing requirements, prompt strategies, and common pitfalls to avoid.

[JaredAung]

Hi! I'd like to work on this issue if it's still available.

[santoshkumarradha]

All yours @JaredAung !

[github-actions]

Thanks for picking this up, @JaredAung! 🎉

Here's what to expect:

• We'll check in after 7 days if we haven't heard an update
• After 14 days, we'll send a second reminder
• After 21 days without activity, we'll unassign to let others contribute

Tips for success:

• Drop a comment when you start working on it
• Share any blockers - we're here to help!
• Link your PR with Fixes #104 in the description

Happy coding! 🚀

[JaredAung]

Just started working on it.

[JaredAung]

Hi,
Just had a question.

retry.go contains two pure helper functions (isRetryableDBError and backoffDelay) — it has no HTTP handler or execution ID parameter. The scenarios in the issue (successful retry submission, invalid/missing execution ID, error response format) are endpoint-level behaviors that belong to the handler that calls these helpers.

Could you clarify:
Should retry_test.go only cover the two helper functions in retry.go?
Or should it also cover the endpoint-level retry scenarios — and if so, against which handler?
Currently I've written tests for both the helpers and a simulated handler flow in retry_test.go, but wanted to confirm the intended scope.

Thank you.

[santoshkumarradha]

Cc @AbirAbbas

[AbirAbbas]

Hey @JaredAung — great catch, you're right. The issue description is inaccurate — retry.go only contains the two pure helper functions (isRetryableDBError and backoffDelay), not any HTTP handler logic. Those endpoint-level scenarios (execution ID handling, retry submission) don't apply to this file.

The scope should just be the two helpers:

• isRetryableDBError: returns true for each retryable fragment, false for nil/unrelated errors
• backoffDelay: scales with attempt number, non-negative durations, edge cases (attempt ≤ 0)

No need to cover endpoint-level retry scenarios in retry_test.go — that logic lives elsewhere. Thanks for flagging!

[JaredAung]

Hey @AbirAbbas, thanks for the clarification — that helped a lot. I’ve now submitted a PR with unit tests covering the two helper functions (isRetryableDBError and backoffDelay). Would appreciate any feedback!