pipe-cd / pipe-cd/pipecd

Refactor: Replace `WaitNext` usages with `Do` in backoff package to avoid panics

Open
#6,995 6 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

kind/bug
Dominant language
Go
Stars
1.4k
Forks
364
Avg merge
1d 4h
Merged PRs (30d)
84

Description

What happened:
The codebase currently contains direct usages of the WaitNext function in the pkg/backoff package. There is a TODO comment at pkg/backoff/backoff.go:65 indicating that using WaitNext directly can lead to panics in certain scenarios, and we need to refactor these usages.

What you expected to happen:
To avoid potential panics and improve stability, all usages of WaitNext outside of the pkg/backoff package should be replaced with the safer Do method. The Do method encapsulates the retry logic and executes operations safely without risking panics from improper loop handling.

How to reproduce it:
This is a proactive code refactoring task rather than a runtime bug reproduction.

  1. Check pkg/backoff/backoff.go line 65 to see the TODO.
  2. Search the codebase for invocations of WaitNext(ctx) on retry interfaces/objects to see where refactoring is needed.

Environment:

  • piped version: N/A (Codebase refactoring)
  • control-plane version: N/A
  • Others: N/A

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at pkg/backoff/backoff.go:65 and inspect the TODO explaining the risks of direct WaitNext usage. Search the codebase for WaitNext(ctx) calls on retry interfaces or objects, then identify every usage outside pkg/backoff. Done means those usages use Do instead and the affected Go tests pass.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
devops
Issue type
Refactor
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.