AlistGo/alist · info

receive timeout

Error message

receive timeout

What it means

'receive timeout' is returned by (*Http).WaitReceive in internal/message/http.go when no message arrives on the Received channel within d seconds. It is the blocking counterpart of 'receive failed': the caller waited a bounded time and the time.After branch fired.

Source

Thrown at internal/message/http.go:75

		return "", errors.New("receive failed")
	}
}

func (p *Http) WaitSend(message Message, d int) error {
	select {
	case p.ToSend <- message:
		return nil
	case <-time.After(time.Duration(d) * time.Second):
		return errors.New("send timeout")
	}
}

func (p *Http) WaitReceive(d int) (string, error) {
	select {
	case message := <-p.Received:
		return message, nil
	case <-time.After(time.Duration(d) * time.Second):
		return "", errors.New("receive timeout")
	}
}

var HttpInstance = &Http{
	Received: make(chan string),
	ToSend:   make(chan Message),
}

View on GitHub (pinned to 843d9dc814)

Solutions

  1. Size d to the expected worst-case inter-message gap for your workload
  2. Treat the timeout as a normal idle result (empty poll) rather than an error path in callers
  3. Confirm the producer endpoint that feeds Received is being called with valid payloads
  4. For tests, use generous timeouts or inject messages before waiting

Example fix

// before
msg, err := message.HttpInstance.WaitReceive(1)
if err != nil { return err }

// after
msg, err := message.HttpInstance.WaitReceive(30)
if err != nil { msg = "" /* idle poll, not an error */ }
Defensive patterns

Strategy: fallback

Validate before calling

// pick d based on expected inter-message interval
// e.g. d = 2 * expectedGap

Type guard

func isReceiveTimeout(err error) bool {
    return err != nil && err.Error() == "receive timeout"
}

Try / catch

msg, err := message.HttpInstance.WaitReceive(d)
if isReceiveTimeout(err) { msg = "" /* idle: normal */ }

Prevention

When it happens

Trigger: WaitReceive(d) invoked when no producer writes to HttpInstance.Received during the window — e.g. no client has submitted a message via the HTTP receive endpoint, or messages are routed elsewhere.

Common situations: Legitimate idle periods with no inbound messages (treat as poll-empty); frontend disconnected; d shorter than the expected message production interval causing spurious timeouts in tests.

Understand the failure class

Related errors


AI-assisted analysis of AlistGo/alist@843d9dc814 (2026-08-15). Data as JSON: /api/errors/8b57063791b8c69f. Report an issue: GitHub.