Repository navigation
fix: preserve DOCX leading content and support explicit repair revisions - #493
Merged
Merged
Conversation
3 of 4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Preserve the four introductory paragraphs before the first level-one heading in the large DOCX. Add an explicit reparse option that requires an existing document ID, allowing the same stored original to repair its revision while preserving the canonical document. Ordinary duplicate uploads, cross-document duplicates and active content claims remain rejected.
Evidence
After: 50 focused tests pass, including database-backed duplicate-content/admission contracts, unchanged ordinary-update rejection, explicit same-document revision repair, long root-body splitting, and progressive DOCX/MD/TXT contracts.
Merge Danger
Door: two-way
Blast Radius: parsing
Existing published snapshots remain immutable. Repair creates a new parse revision under the existing document ID. The explicit option defaults to false; normal content deduplication remains in place.
Production acceptance: the repaired final contains all 768 full original paragraphs, all 16 complete image paths, and the end sentinel. The same Hipo Source and Knowhere canonical document are preserved, with one explicit repair parse revision. Live deployment and deadline/SIGKILL/resume evidence are recorded in Ontos-AI/hipo#452 (follow-up #453).