Vector deliveries and deletion
Read delivered chunk entries without confusing them with an exact vector-store inventory.
A vector connection identifies one collection. Its browser lists chunk deliveries recorded from workflows. That list is useful provenance, but it is not an exact census of the vectors currently stored in the collection.
Delivered versus stored
Re-running a workflow can create another delivery entry for a chunk that the vector store still holds once. Conversely, a stored vector can lack a preview entry if recording that preview failed. Read the note explaining this distinction, and treat the displayed count as delivered entries rather than a stored-vector total.
Expand an entry to inspect its available text and information. Load additional pages when available. An unavailable listing or failed request should not be read as proof that the collection is empty.
Delete by vector identity
Deleting an entry targets its vector reference. Multiple delivery rows can share that reference, so one deletion can affect more than the one row you clicked. Review the confirmation and identify the intended chunk before continuing.
Bulk deletion deduplicates references and processes large selections in batches of up to 100 references. The selected-entry count and the count of stored vectors actually deleted can differ. Results distinguish deleted, already gone, failed, interrupted, and unattempted entries.
An already absent vector is the requested end state, but it is not counted as a newly deleted vector. A failed or interrupted entry remains selected for investigation or retry. A partial response is not a rollback of earlier successful batches.
Rebuilding
Vector deletion has no trash or automatic undo. Rebuilding requires re-running the relevant embedding workflow. The source document and its App copy have their own lifecycle; removing a vector is not proof that those sources were erased.