Tencent/WeKnora · warning

attachment %s is still being processed

Error message

attachment %s is still being processed

What it means

The attachment exists but its status is neither Ready nor Failed — asynchronous processing has not finished yet, so there is no parsed content to resolve into the prompt. The error reports the file name.

Source

Thrown at internal/application/service/temporary_document.go:623

	}
	seen := make(map[string]struct{}, len(documentIDs))
	for _, documentID := range documentIDs {
		if _, duplicate := seen[documentID]; duplicate {
			continue
		}
		seen[documentID] = struct{}{}
		document, err := s.repo.GetScoped(ctx, tenantID, sessionID, documentID)
		if err != nil {
			return nil, err
		}
		if document == nil {
			return nil, fmt.Errorf("attachment %s was not found in this session", documentID)
		}
		if document.Status != types.TemporaryDocumentStatusReady {
			if document.Status == types.TemporaryDocumentStatusFailed {
				return nil, fmt.Errorf("attachment %s failed to parse: %s", document.FileName, document.ErrorMessage)
			}
			return nil, fmt.Errorf("attachment %s is still being processed", document.FileName)
		}
		content, selected, total := selectTemporaryDocumentContentWithBudget(document, query, perDocumentBudget)
		result.Attachments = append(result.Attachments, types.MessageAttachment{
			ID: document.ID, URL: document.ResourceRef, FileName: document.FileName,
			FileType: document.FileType, FileSize: document.FileSize, Content: content,
			ContentMode: map[bool]string{true: "full", false: "selected_chunks"}[selected == total],
			TokenCount:  document.TokenCount, SelectedChunks: selected, TotalChunks: total,
		})
		// Image-type attachments always expose their image so vision models can
		// see it directly; text documents only attach extracted images when the
		// question is visual, to avoid gratuitous multimodal latency.
		if docparser.IsImageFormat(document.FileType) || isVisualDocumentQuery(query) {
			for _, image := range temporaryDocumentImageRefs(document.ImageRefs) {
				if image.URL != "" && len(result.ImageURLs) < 4 {
					result.ImageURLs = append(result.ImageURLs, image.URL)
				}
			}
		}

View on GitHub (pinned to 988cbb0330)

Solutions

  1. Wait for the document status to become READY (poll or subscribe to processing events) before sending the message
  2. Add client-side gating that disables sending until all attachments are ready
  3. Implement retry-with-backoff on ResolveForPrompt until the document completes
  4. Investigate parser queue throughput if processing is persistently slow

Example fix

// before
result, err := svc.ResolveForPrompt(ctx, tenantID, sessionID, ids, query)
// after
waitUntilReady(ctx, svc, tenantID, sessionID, ids) // poll status == READY
result, err := svc.ResolveForPrompt(ctx, tenantID, sessionID, ids, query)
Defensive patterns

Strategy: retry

Validate before calling

doc, _ := repo.GetScoped(ctx, tenantID, sessionID, documentID)
if doc != nil && doc.Status != types.TemporaryDocumentStatusReady { /* wait */ }

Try / catch

if strings.Contains(err.Error(), "still being processed") {
    time.Sleep(backoff) // retry ResolveForPrompt with backoff until READY
}

Prevention

When it happens

Trigger: ResolveForPrompt is called while the document's async parse (Process) is still running — Status is PENDING/PROCESSING rather than TemporaryDocumentStatusReady.

Common situations: Client sends the chat message immediately after upload without waiting for the parse-complete callback/WS event; large documents that take a long time to parse; queue backlog delaying processing.

Related errors


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