Tencent/WeKnora · warning

attachment 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.

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.

Appendix: 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)