Back to releases
v0.7.7

Feishu sync is more reliable (v0.7.7)

Stable incremental document sync, safe increment cursors, forced re-sync, and deletion policies ship, so large collaboration spaces sync without dropping content or deleting the wrong thing.

FeishuSource syncRobustness

v0.7.4 let a knowledge base connect to Feishu; this release polishes it into a sync that can run long-term in a real collaboration space: content changes update incrementally by document identity, an interruption never deletes the wrong data, and oversized documents and deletions are handled by policy.

Incremental sync, not a full re-run

Sync is rewritten as an incremental flow based on stable Document identity:

  • The same Feishu document reuses its identity across syncs; if the content hash is unchanged, it’s skipped instead of creating a new revision.
  • Deletion is gated by snapshot completeness: only a snapshot that listed successfully executes deletions and advances the cursor; partial listings (rate-limit, paging failure) keep the existing data and drop nothing.
  • The cursor is computed from the successful prefix of document EditTimes, so sync progress can never move past a node that hasn’t finished processing.

Forced re-sync

When you need to re-pull an entire knowledge base, a force sync bypasses the incremental check: a force intent merges with an existing sync request and reuses the task instead of re-enqueuing; marking force again while a task is running auto-follows with another pass after the current task ends, so no request is lost.

Deletion policy and object cleanup

When deleting a Feishu document, you can choose to keep or remove per knowledge-base config:

  • The remove policy deletes the original object, parse artifacts, and image assets in async batches; a deleted job that runs again just skips.
  • Under the keep policy, the document is excluded from retrieval and stats but the underlying object is not deleted.
  • Folders cascade-clean by external ID, and empty directories are reclaimed within the same sync round, instead of needing multiple syncs to clear.

Boundaries and stability

  • When document content exceeds the limit (default 50 MiB), the new document isn’t persisted and the existing document keeps its old version; sync doesn’t break on a single oversized document.
  • Advancing the sync task’s terminal state is idempotent, so an asynq retry of an already-finished task doesn’t re-run the sync or create duplicate follow-up tasks.
  • The MCP knowledge_search tool is marked read-only and side-effect-free, so clients can call it with more confidence; the API Keys form fills in the knowledge_bases read scope, aligning the scope contract front and back.