Potential memory leak

[dnozdrin]

Usage of <-time.After(c.Timeout) here may lead to memory leak.

timeout := time.After(r.calcSleep(retries))

According to the official time package docs:

After waits for the duration to elapse and then sends the current time on the returned channel. It is equivalent to NewTimer(d).C. The underlying Timer is not recovered by the garbage collector until the timer fires. If efficiency is a concern, use NewTimer instead and call Timer.Stop if the timer is no longer needed.

Possible solution:

func (r *Retrier) RunCtx(ctx context.Context, work func(ctx context.Context) error) error {
	retries := 0
	for {
		ret := work(ctx)

		switch r.class.Classify(ret) {
		case Succeed, Fail:
			return ret
		case Retry:
			if retries >= len(r.backoff) {
				return ret
			}

			timer := time.NewTimer(r.calcSleep(retries))
			if err := r.sleep(ctx, timer); err != nil {
				return err
			}

			retries++
		}
	}
}

func (r *Retrier) sleep(ctx context.Context, timer *time.Timer) error {
	select {
	case <-timer.C:
		return nil
	case <-ctx.Done():
		if !timer.Stop() {
			<-timer.C
		}

		return ctx.Err()
	}
}

References:

1. A story of a memory leak in GO: How to properly use time.After()
2. Use "time.After" may cause a memory leak eclipse/paho.mqtt.golang#518
3. Golang <-time.After() is not garbage collected before expiry
4. time: Timer.Stop documentation example easily leads to deadlocks golang/go#27169