@alexkroman1/aai-ui 6.5.1 → 6.7.0

package/dist/index.js

@@ -1849,14 +1849,18 @@ function useWorkflowRuns(workflow, opts = {}) {
 * - **Reporting the bytes.** The same `UploadStatus` `useWorkflowSubmit` reports,
 *   so `<UploadProgressBar>` renders either without knowing which hook it came from.
 *
-* ## A failed upload CANCELS the run
+* ## A failed upload is RESUMED once, and only then cancels the run
 *
 * An upload that dies stays in the store, incomplete, and `complete` never becomes
 * true — so a run left behind polls until its own abandonment bound and then fails,
-* minutes after the page has already reported the error. Cancelling is the honest
-* end to a submission that did not happen. The cost is that work already done is
-* thrown away with the run; a caller who wants to resume instead drives
-* `api.uploadStream` and `api.uploadInfo` directly.
+* minutes after the page has already reported the error.
+*
+* That used to be the whole story, and it threw away a run and a file together for
+* what is usually one dropped connection near the end. So a failure gets one more
+* attempt with `resume: true`, which sends only the windows the store does not
+* already have (`UploadInfo.ranges`) — the run is still waiting on the same id, so
+* a resume that succeeds is invisible to it. Cancelling is what happens when THAT
+* fails too, and it is the honest end to a submission that did not happen.
 */
 /**
 * Start a workflow run and stream a file into it while it works.
@@ -1913,16 +1917,22 @@ function useWorkflowStream(workflow, opts = {}) {
 				started = await client.start(workflow, payload, omitUndefined({ key }));
 				setRunId(started);
 				if (!chosen) return;
-				await client.uploadStream(id, chosen, {
-					name: chosen.name,
-					onProgress: (progress) => setUpload({
-						...progress,
+				const send = async (resume) => {
+					await client.uploadStream(id, chosen, {
 						name: chosen.name,
-						index: 1,
-						count: 1
-					}),
-					...omitUndefined({ parallel })
-				});
+						onProgress: (progress) => setUpload({
+							...progress,
+							name: chosen.name,
+							index: 1,
+							count: 1
+						}),
+						...omitUndefined({
+							parallel,
+							resume: resume ? true : void 0
+						})
+					});
+				};
+				await send(false).catch(async () => await send(true));
 				await client.wake(started).catch(() => void 0);
 			} catch (err) {
 				setStartError(errorMessage(err));

package/dist/use-workflow-form.d.ts

@@ -141,13 +141,14 @@ export type UseWorkflowSubmitOptions = {
     /**
      * Send each chosen file as concurrent parts instead of in one request.
      *
-     * `true` for the defaults, or `{ partBytes, concurrency }` to tune them. This is
-     * the wait a form with a recording in it actually spends: the run does not exist
-     * until its input is stored, so until the last byte lands there is no run to
-     * watch and nothing for `<WorkflowProgress>` to say. Splitting the file across
-     * connections is what makes that stretch shorter, and it degrades to the single
-     * request wherever it would not help — a small file, an older agent — so turning
-     * it on is safe for every form. See `UploadOptions.parallel`.
+     * **On by default.** `false` opts out, `{ partBytes, concurrency }` tunes it.
+     * This is the wait a form with a recording in it actually spends: the run does
+     * not exist until its input is stored, so until the last byte lands there is no
+     * run to watch and nothing for `<WorkflowProgress>` to say. Splitting the file
+     * across connections is what makes that stretch shorter, and it degrades to the
+     * single request wherever it would not help — a small file, an older agent — so
+     * the default costs nothing where it would not have paid. See
+     * `UploadOptions.parallel`.
      */
     parallel?: UploadParallel;
 };

package/dist/use-workflow-stream.d.ts

@@ -48,14 +48,18 @@
  * - **Reporting the bytes.** The same `UploadStatus` `useWorkflowSubmit` reports,
  *   so `<UploadProgressBar>` renders either without knowing which hook it came from.
  *
- * ## A failed upload CANCELS the run
+ * ## A failed upload is RESUMED once, and only then cancels the run
  *
  * An upload that dies stays in the store, incomplete, and `complete` never becomes
  * true — so a run left behind polls until its own abandonment bound and then fails,
- * minutes after the page has already reported the error. Cancelling is the honest
- * end to a submission that did not happen. The cost is that work already done is
- * thrown away with the run; a caller who wants to resume instead drives
- * `api.uploadStream` and `api.uploadInfo` directly.
+ * minutes after the page has already reported the error.
+ *
+ * That used to be the whole story, and it threw away a run and a file together for
+ * what is usually one dropped connection near the end. So a failure gets one more
+ * attempt with `resume: true`, which sends only the windows the store does not
+ * already have (`UploadInfo.ranges`) — the run is still waiting on the same id, so
+ * a resume that succeeds is invisible to it. Cancelling is what happens when THAT
+ * fails too, and it is the honest end to a submission that did not happen.
  */
 import type { UploadParallel } from "@alexkroman1/aai/workflow-api";
 import type { UploadStatus } from "./use-workflow-form.ts";
@@ -77,8 +81,8 @@ export type UseWorkflowStreamOptions = {
      * the uplink sees the same growing file whether one connection or four are
      * filling it. What changes is only how fast it grows.
      *
-     * `true` for the defaults, or `{ partBytes, concurrency }` to tune them. See
-     * `UploadOptions.parallel`.
+     * **On by default.** `false` opts out, `{ partBytes, concurrency }` tunes it.
+     * See `UploadOptions.parallel`.
      */
     parallel?: UploadParallel;
 };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@alexkroman1/aai-ui",
-  "version": "6.5.1",
+  "version": "6.7.0",
   "type": "module",
   "files": [
     "dist",
@@ -29,7 +29,7 @@
     "remark-gfm": "^4.0.1",
     "use-stick-to-bottom": "^1.1.6",
     "use-sync-external-store": "^1.6.0",
-    "@alexkroman1/aai": "6.5.1"
+    "@alexkroman1/aai": "6.7.0"
   },
   "peerDependencies": {
     "react": "^19.0.0",