Tencent/WeKnora · error

summary generation exhausted retries: %w

Error message

summary generation exhausted retries: %w

What it means

Terminal error returned after summary generation exhausted its retry budget. By the time it is returned, a degraded fallback (first chunk or empty summary) has already been persisted to the knowledge record, so this error signals stage outcome, not data loss.

Source

Thrown at internal/application/service/knowledge_process.go:1215

		if stale {
			logger.Infof(ctx, "Discarding stale summary fallback for knowledge %s", payload.KnowledgeID)
			summaryOut["skipped"] = "content_revision_changed"
			return nil
		}

		fallback := applyRetryableSummaryFailureState(knowledge, textChunks, false)
		if updateErr := s.repo.UpdateKnowledge(ctx, knowledge); updateErr != nil {
			logger.Errorf(ctx, "Failed to save terminal summary fallback: %v", updateErr)
			summaryErr = updateErr
			return fmt.Errorf("save terminal summary fallback: %w", updateErr)
		}
		if fallback == "" {
			summaryOut["fallback"] = "empty"
		} else {
			summaryOut["fallback"] = "first_chunk"
		}
		summaryOut["fallback_chars"] = len([]rune(fallback))
		return fmt.Errorf("summary generation exhausted retries: %w", generationErr)
	}

	// Initialize chat model for summary. Model resolution failures use the same
	// retry budget and terminal first-chunk fallback as LLM request failures.
	chatModel, err := s.modelService.GetChatModel(ctx, kb.SummaryModelID)
	if err != nil {
		logger.Errorf(ctx, "Failed to get chat model: %v", err)
		return handleRetryableSummaryFailure(fmt.Errorf("get chat model: %w", err))
	}

	// Generate summary
	summary, err := s.getSummary(ctx, chatModel, knowledge, textChunks)
	if err != nil {
		logger.Errorf(ctx, "Failed to generate summary for knowledge %s: %v", payload.KnowledgeID, err)
		// Surface the underlying LLM/IO error on the span so the trace UI
		// can explain "why did this stage take 60s and then fall back?"
		// without forcing the operator to grep worker logs. We also capture
		// the error type to disambiguate timeouts from upstream HTTP errors

View on GitHub (pinned to 988cbb0330)

Solutions

1. Inspect summaryOut['error']/['error_type'] on the span to identify the LLM/IO root cause (timeout, upstream 5xx, quota)
2. Fix the underlying model/config issue, then re-trigger summary regeneration
3. The knowledge remains searchable via chunks with the fallback summary until then

When it happens

Trigger: Thrown at internal/application/service/knowledge_process.go:1215 when the library encounters an invalid state.

Common situations: See trigger scenarios.

AI-assisted analysis of Tencent/WeKnora@988cbb0330 (2026-09-02). Data as JSON: /api/errors/d702fd912e2b39c6. Report an issue: GitHub.