← ZillizCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Zilliz
Snapshot Sep 30, 2026 · 23:15 UTC · version 1.4.4
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Use when the user wants to trigger, describe, or list refresh jobs for an external collection (a collection backed by an external data source such as Vector Lake). Note this is the data-plane refresh workflow, not collection CRUD -- for create/drop/load see the collection skill.",
"included_files": [],
"name": "external-collection",
"skill_md_contents": "---\nname: external-collection\ndescription: Use when the user wants to trigger, describe, or list refresh jobs for an external collection (a collection backed by an external data source such as Vector Lake). Note this is the data-plane refresh workflow, not collection CRUD -- for create/drop/load see the collection skill.\n---\n\n## Prerequisites\n\n1. CLI installed, logged in, and cluster context set (see setup skill).\n2. The target collection must already exist as an **external collection**\n (created with an `externalSource` / `externalSpec` schema in the\n collection skill). Plain in-place collections do not have refresh jobs.\n3. The cluster must be running a `kite-coordinator` build that exposes\n `/v2/vectordb/jobs/external_collection/*` (PR #5735 or later). On older\n data planes the API returns 404 -- in that case ask the user to upgrade\n the cluster.\n\n## Commands Reference\n\nThe `external-collection` resource has a single operation, `refresh`, with\nthree actions: `trigger`, `describe`, and `list`. All three are data-plane\ncalls and inherit the database from the current context unless overridden\nwith `--database`.\n\n### Trigger a refresh job\n\n```bash\nzilliz external-collection refresh trigger --name <collection-name>\n# Optional:\n# --database <db-name> Override the context database\n# --external-source <src> Override the external source registered on the collection\n# --external-spec <spec> Override the external spec registered on the collection\n```\n\n`trigger` returns the new `jobId`. Use it with `refresh describe` to poll\nstatus. The override flags are intentionally rare -- normally the source\nand spec are pinned at collection-create time, and a plain\n`refresh trigger --name <name>` is enough.\n\n### Describe a refresh job\n\n```bash\nzilliz external-collection refresh describe --job-id <id>\n```\n\nReturns the job's state, progress, and (on failure) the error message.\n\n### List refresh jobs\n\n```bash\nzilliz external-collection refresh list\n# Optional:\n# --name <collection-name> Filter to one external collection\n# --database <db-name> Override the context database\n```\n\nWithout filters, `list` returns recent refresh jobs scoped to the current\ndatabase. Pair with `--query` to extract a single field, e.g.:\n\n```bash\nzilliz external-collection refresh list --name my_external_coll \\\n --query 'data[?state==`Pending` || state==`Running`].jobId'\n```\n\n## Guidance\n\n- An external collection is a collection whose rows live in an external\n source (e.g. a Vector Lake table). The collection's metadata, indexes,\n and schema are in Milvus, but the data is pulled in on demand. The\n `refresh` job is what synchronises that external data into the\n collection so subsequent queries see fresh rows.\n- Refresh jobs are asynchronous. After `trigger`, poll with `describe`\n until the job reaches a terminal state. Do not assume completion just\n because `trigger` returned successfully -- that only means the job was\n accepted.\n- If `trigger` fails with \"collection not found\" or \"not an external\n collection\", verify with `zilliz collection describe --name <name>`\n that the collection actually has an `externalSource` field. If it\n does not, this is a normal in-place collection and refresh does not\n apply -- nothing needs to be done.\n- When `describe` reports a failed job, surface the error message to the\n user verbatim. It usually points at a credentials, network, or schema\n mismatch in the external source rather than a Milvus bug.\n- Avoid scheduling overlapping refresh jobs against the same collection\n -- check `list --name <name>` for an already-running job before\n triggering a new one.\n- A `trigger` on a large external table can run for minutes. Do not\n hold a chat session open polling every few seconds -- give the user\n the `jobId` and explain how to come back and check `describe` later.\n- For related operations on the same collection (create, drop, load,\n query) defer to the `collection` skill. This skill only covers the\n refresh lifecycle.\n"
}SHA-256 of public snapshot: 44c8c3695c7cff714f6e6cc4da8fe9c089d5b9a3028d0361d65607dd81690937