2 Commits

Author	SHA1	Message	Date
槑囿脑袋	2250ccb52f	feat(knowledge): integrate file processing for document ingestion (#15470) ... Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: fullex <106392080+0xfullex@users.noreply.github.com> Signed-off-by: eeee0717 <chentao020717Work@outlook.com> Signed-off-by: icarus <eurfelux@gmail.com>	2026-05-31 23:10:36 +08:00
槑囿脑袋	01e7e31a8e	feat(v2): add main-side file processing backend (#13968) ... ### What this PR does Before this PR: File processing on the `v2` branch was still described and wired around split OCR / markdown APIs, legacy feature names, and feature-first provider structure. OCR-like image text extraction and document-to-markdown conversion did not share one task contract, and provider task ids / polling details were harder to keep behind the Main-process boundary. After this PR: `v2` file processing follows `v2-refactor-temp/docs/fileProcessing/file-processing-service.md` as the design baseline: - exposes one Main-side task API: `startTask`, `getTask`, and `cancelTask` - replaces split file-processing IPC with `file-processing:start-task`, `file-processing:get-task`, and `file-processing:cancel-task` - renames features and preference keys to `image_to_text` and `document_to_markdown` - adds `FileProcessingTaskService` as the in-memory source of truth for task ids, task state, progress, cancellation, TTL pruning, remote-poll dedupe, and task change events - keeps provider task ids, remote context, query context, abort controllers, and in-flight polling inside Main-process task records - maps completed results to artifacts: inline `text/plain` for `image_to_text`, and persisted markdown file artifacts for `document_to_markdown` - reorganizes providers into processor-first handlers under `src/main/services/fileProcessing/processors` - moves Tesseract worker ownership under `processors/tesseract/runtime` - removes the new file-processing module's old `ocr/` and `markdown/` split directories after migrating their logic - updates shared schemas, presets, preference generation, migration mappings, and tests for the renamed feature model The public file-processing contract is now: ```ts await window.api.fileProcessing.startTask({ feature: 'image_to_text', file, processorId: 'tesseract' }) await window.api.fileProcessing.getTask({ taskId }) await window.api.fileProcessing.cancelTask({ taskId }) ``` Architecture overview: ```text Renderer / upper-layer caller | | startTask / getTask / cancelTask v FileProcessingOrchestrationService | | Zod validation + delegation v FileProcessingTaskService | | taskId, task store, TTL, cancellation, | background execution, remote polling, artifacts v processorRegistry[processorId].capabilities[feature] | +--> image-to-text handlers | -> text/plain artifact | +--> document-to-markdown handlers -> feature.files.data/fileId/file-processing/taskId/output.md ``` Notes: - The new file-processing API does not keep facades for `file-processing:extract-text`, `file-processing:start-markdown-conversion-task`, or `file-processing:get-markdown-conversion-task-result`. - `FileProcessingOrchestrationService` is intentionally only the IPC validation and delegation layer. - Task state is Main-process runtime coordination state, not DataApi or Cache state. - Renderer task subscriptions, a global UI task center, and full renderer business-flow migration are intentionally out of scope for this PR. - The legacy standalone OCR path outside the new file-processing module can coexist during the v2 transition, but the new file-processing interface is not polluted by those split-API types. Fixes #N/A ### Why we need it and why it was done in this way This PR makes OCR-style image text extraction and document-to-markdown conversion use the same Main-process task model before renderer-side adoption. The unified contract gives upper layers one way to start work, query progress, handle failure, cancel work, and consume completed artifacts without learning provider-specific polling details. The following tradeoffs were made: - Fast OCR now also goes through a task API, so callers need start/query behavior instead of a direct `extractText -> text` call. - Task state remains session-scoped in memory; completed artifacts are persisted, but task snapshots are not restored after app restart. - Remote-provider cancellation is best-effort: local polling and state transition stop immediately, but third-party provider-side cancellation is not guaranteed. - Renderer integration is intentionally compile-safe and minimal in this PR; full UX migration should happen in follow-up changes. - Tesseract keeps a processor-owned runtime service, while other processors stay as handlers/utilities until they need lifecycle-managed resources. The following alternatives were considered: - Keeping separate OCR and markdown conversion APIs, which would preserve the current split but continue duplicating task, progress, cancellation, and result semantics. - Adding a DataApi task table or Cache mirror for file-processing task state, which would create a second source of truth for runtime coordination state. - Adding renderer push subscriptions in this PR, which would expand the scope beyond the Main-side task contract. - Introducing a generic process manager for all processors, which is premature while only Tesseract currently owns reusable lifecycle resources. Links to places where the discussion took place: `v2-refactor-temp/docs/fileProcessing/file-processing-service.md` ### Breaking changes None for released user-facing behavior. If this PR introduces breaking changes, please describe the changes and the impact on users. For the in-progress `v2` file-processing integration, this replaces the split file-processing IPC/preload shape with the unified `startTask/getTask/cancelTask` contract. It also renames file-processing feature and preference keys from the old `text_extraction` / `markdown_conversion` model to `image_to_text` / `document_to_markdown`. ### Special notes for your reviewer - This PR targets `v2`, not `main`. - Review this against `v2-refactor-temp/docs/fileProcessing/file-processing-service.md`; that document is the source of truth for the module boundary. - Main review points: unified task API, artifact model, cancellation semantics, processor-first registry/handlers, hidden provider runtime state, and no DataApi/Cache task storage. - `document_to_markdown` artifacts are persisted under `application.getPath('feature.files.data')/fileId/file-processing/taskId/output.md`. - `image_to_text` artifacts are returned inline as plain text artifacts and are not persisted. - Current local verification status: - `pnpm format`: passed - `pnpm build:check`: passed - Vitest inside `build:check`: `432` test files passed, `7171` tests passed, `72` skipped ### Checklist This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR. Approvers are expected to review this list. - [x] PR: The PR description is expressive enough and will help future contributors - [x] Code: [Write code that humans can understand](https://en.wikiquote.org/wiki/Martin_Fowler#code-for-humans) and [Keep it simple](https://en.wikipedia.org/wiki/KISS_principle) - [x] Refactor: You have [left the code cleaner than you found it (Boy Scout Rule)](https://learning.oreilly.com/library/view/97-things-every/9780596809515/ch08.html) - [x] Upgrade: Impact of this change on upgrade flows was considered and addressed if required - [ ] Documentation: A [user-guide update](https://docs.cherry-ai.com) was considered and is present (link) or not required. Check this only when the PR introduces or changes a user-facing feature or behavior. - [x] Self-review: I have reviewed my own code (e.g., via [`/gh-pr-review`](/.claude/skills/gh-pr-review/SKILL.md), `gh pr diff`, or GitHub UI) before requesting review from others ### Release note ```release-note NONE ``` --------- Signed-off-by: eeee0717 <chentao020717Work@outlook.com> Co-authored-by: fullex <106392080+0xfullex@users.noreply.github.com>	2026-05-08 21:25:03 +08:00