Skip to content

v1.3.7 — Soft-delete / Trash + workflow autowrap fix

Choose a tag to compare

@yeldarby yeldarby released this 29 Apr 04:09
· 31 commits to main since this release
d384863

Soft-delete / Trash support — SDK + CLI

Mirrors the soft-delete and Trash features added to the Roboflow web app (roboflow/roboflow#11131). Deleting a project, version, or workflow now moves it to Trash with a 30-day retention window (and cancels any in-flight training jobs); items can be restored within that window. Companion docs: roboflow-dev-reference#5.

SDK

  • Project.delete() — soft-deletes the project. Returns the server response.
  • Project.restore() — looks the project up in the workspace Trash by slug and restores it; raises RuntimeError if not currently in Trash.
  • Version.delete() / Version.restore() — same shape on a version handle.
  • Workspace.trash() — lists everything in a workspace's Trash, grouped by projects / versions / workflows. Returns the raw API payload (so you have access to parentId, parentUrl, scheduledCleanupAt, etc.).
  • Workspace.restore_from_trash(item_type, item_id, parent_id=None) — restores by id when you don't have a live SDK handle. item_type is "project", "version", or "workflow"; parent_id is required when restoring a version.
import roboflow
rf = roboflow.Roboflow(api_key="...")
ws = rf.workspace()

# Discover what's in Trash
trash = ws.trash()
for item in trash["items"]:
    print(item["type"], item["name"], "cleanup:", item["scheduledCleanupAt"])

# Restore a project you don't have a handle for
project_in_trash = trash["sections"]["projects"][0]
ws.restore_from_trash("project", project_in_trash["id"])

CLI

roboflow project delete <slug>      [--yes] [--json]
roboflow project restore <slug>     [--yes] [--json]
roboflow version delete <slug>/<v>  [--yes] [--json]
roboflow version restore <slug>/<v> [--yes] [--json]
roboflow workflow delete <url>      [--yes] [--json]
roboflow workflow restore <url>     [--yes] [--json]
roboflow trash list                 [--json]

Destructive commands prompt for confirmation interactively; pass --yes / -y for scripted use. Every command supports --json for structured output and emits actionable hints with stable exit codes (0 success, 1 error, 2 auth, 3 not-found).

Low-level (roboflow.adapters.rfapi)

New helpers: delete_project, delete_version, delete_workflow, list_trash, restore_trash_item. RoboflowError messages now extract the error field from JSON response bodies (e.g. "Not authorized to view trash") instead of returning raw response text.

Permanent deletion is intentionally web-UI-only

Emptying Trash and immediately deleting a single Trash item destroy data irrecoverably and live only in the Roboflow app's Trash view, which has an explicit confirmation dialog. Items left in Trash are cleaned up automatically after 30 days. Guard tests in this release ensure those actions stay off the SDK/CLI surface going forward.

Fixed — workflows created via SDK/CLI now execute successfully

Workspace.create_workflow() and roboflow workflow create --definition now auto-wrap bare workflow definitions in {"specification": ...} before POSTing to the backend, matching what the web app does (#460). Previously, the user-facing flat shape ({version, inputs, steps, outputs}) — the shape published in the Workflows docs — was sent verbatim, so executing the resulting workflow returned HTTP 502 with MalformedWorkflowResponseError: Workflow specification not found in Roboflow API response.

Workflows already wrapped (top-level specification key) are passed through unchanged. Non-workflow dicts and non-JSON strings are also passed through verbatim so custom payloads aren't second-guessed.

Workflows that were stored with the bare shape before this fix will still 502 until re-saved. Run roboflow workflow update <url> --definition <file> once per affected workflow to migrate.

Other changes

  • upload_image no longer re-encodes images client-side (#464) — uploads original bytes instead of round-tripping through JPEG.

Backward compatibility

Purely additive on the public API surface. The new endpoints require project:update, version:update, or workflow:update scopes — most existing keys already have these.

Action Required scope
project delete / project restore project:update
version delete / version restore version:update
workflow delete / workflow restore workflow:update
trash list project:read

Full diff: v1.3.6...v1.3.7