Cropwright — Ingest Upload Run

Cropwright — Ingest Upload Run A workflow diagram generated by Archify. 01 / Operator 02 / Upload run controller 03 / OpenProcessor API Prefilter + plan Upload Gate + handoff Select files · files or drag-drop · Operator › Prefilter + plan Select files files or drag-drop Clustering handoff · AutoLabelPanel gate · Operator › Gate + handoff Clustering handoff AutoLabelPanel gate path_lookup · skip indexed ids · Upload run controller › Prefilter + plan path_lookup skip indexed ids Chunk plan · image + byte caps · Upload run controller › Prefilter + plan Chunk plan image + byte caps Upload chunks · concurrency 2 · Upload run controller › Upload Upload chunks concurrency 2 Region drain · drained verdict · Upload run controller › Gate + handoff Region drain drained verdict 413 / 422 / 503 · halve+retry, fail, or pause · OpenProcessor API › Upload 413 / 422 / 503 halve+retry, fail, or pause 200 OK · by source_identifier · OpenProcessor API › Upload 200 OK by source_identifier stable for N polls backend 413: retry halved; 503: resume skip duplicates Legend User UI Agent logic Policy Context / trace

Identifiers, not paths, drive dedup

  • • ${identifierPrefix}${relPath} is computed client-side and matched exactly server-side against image_path or source_identifier
  • • Two folders that both contain img001.jpg at their root would otherwise collide without the source-tag prefix

413 has two shapes, one client rule

  • • A JSON 413 body (the backend's own limit) halves the chunk and retries once
  • • An HTML 413 body (nginx's client_max_body_size) stops the run outright — retrying would just repeat the same rejection

No client-side stability window

  • • The drained verdict (drained/stable_for_s/observed_at) is entirely server-computed from consecutive region_drain polls
  • • The clustering handoff gate reads that served verdict directly rather than reinventing a stability heuristic