What causes "重试 %d 次后失败: %w" in fish2018/pansou?

Check network egress and DNS from the deployment environment (curl the LingJi endpoint)

fish2018/pansou · error

重试次后失败

Error message

重试 %d 次后失败: %w

What it means

doLingjiGET retries an HTTP GET against the LingJi API up to lingjiMaxRetries with exponential backoff. When every attempt fails it aborts the search/detail fetch and wraps the last underlying error with this message. It signals a persistent upstream/network failure, not a caller mistake.

Solutions

Check network egress and DNS from the deployment environment (curl the LingJi endpoint)
Inspect the wrapped lastErr (via errors.Unwrap/%v) to identify the actual cause
Verify the LingJi base URL is current; update if the upstream moved
Increase lingjiMaxRetries or backoff if failures are transient under load
If upstream is rate-limiting, add client-side rate limiting or caching

Example fix

// before
items, err := doLingjiGET(url)
if err != nil { return err }
// after
items, err := doLingjiGET(url)
if err != nil {
    log.Printf("lingji upstream unavailable: %v", err)
    return model.ErrUpstreamUnavailable
}

Defensive patterns

Strategy: retry

Validate before calling

// preflight
resp, err := http.Head(lingjiBaseURL + "/health")
if err != nil || resp.StatusCode != 200 { skipPlugin("lingji unreachable") }

Try / catch

items, err := doLingjiGET(url)
if err != nil {
    log.Printf("lingji failed after retries: %v", err)
    return fallbackPlugin.Search(kw) // degrade gracefully
}

Prevention

Health-check the upstream before enabling the plugin
Always inspect the wrapped lastErr, not just the wrapper message
Cache successful responses to reduce upstream dependence

When it happens

Trigger: All lingjiMaxRetries HTTP attempts fail (connection error, timeout, non-200) inside doLingjiGET, invoked from fetchSearchItems or fetchDetail; the final error is the wrapped lastErr.

Common situations: LingJi API is down or rate-limiting the host; no outbound network/DNS in the container; the endpoint URL changed; TLS/proxy issues; upstream returning 5xx on every retry.

Understand the failure class

Background: 'Something went wrong' / 'Request failed (500)' / 'HTTP error! status: 404' — what failed HTTP requests actually mean and how to find the real cause — this error's family across 28 libraries.

Related errors

AI-assisted analysis of fish2018/pansou@beaa561337 (2026-09-07). Data as JSON: /api/errors/0407728db9203868. Report an issue: GitHub.

Appendix: source

Thrown at plugin/lingjisp/lingjisp.go:286

				}
			}
		} else {
			if resp != nil {
				resp.Body.Close()
			}
			lastErr = err
			if lastErr == nil {
				lastErr = fmt.Errorf("HTTP %d", resp.StatusCode)
			}
		}
		cancel()

		if attempt < lingjiMaxRetries-1 {
			time.Sleep(200 * time.Millisecond * time.Duration(1<<attempt))
		}
	}

	return nil, fmt.Errorf("重试 %d 次后失败: %w", lingjiMaxRetries, lastErr)
}

func dedupeLingjiItems(items []lingjiVideoItem) []lingjiVideoItem {
	seen := make(map[int]struct{})
	results := make([]lingjiVideoItem, 0, len(items))

	for _, item := range items {
		id := chooseLingjiID(item)
		if id == 0 {
			continue
		}
		if _, ok := seen[id]; ok {
			continue
		}
		seen[id] = struct{}{}
		results = append(results, item)
	}
	return results

View on GitHub (pinned to beaa561337)

重试 次后失败