01 / Client release brief

A small API migration.
A complete handoff.

Swiftia video-to-shorts workflow · A review of the request, status and downstream delivery changes a consultant needs to explain before release.

Self-initiated analysis of historical public source. Pages 1–3 show the documented review and eight full-workflow acceptance cases, all awaiting execution in the target environment. Page 4 adds an isolated n8n execution example under a separate service scope.

34nodes per version
including 6 notes

4changed nodes
6 parameter paths

0changed
connections

22potentially
affected nodes

What changes for this release

01 · Generate shorts

generateShorts moves youtubeVideoId into options, removes videoSource and adds an empty webhook.

Verify: the intended video reaches a provider-accepted request body.

02 · Render each item

renderShort replaces id, target and a computed styling key with shortId and renderOptions.

Verify: current-item ID and styling remain paired; serialized types are accepted.

03 · Recognize completion

iscompleted ? changes type = done to the exact comparison status = COMPLETED.

Verify: completion exits polling and reaches metadata generation.

04 · Handle failure

isError ? changes type = error to status = FAILED. Its true branch returns to renderShort.

Verify: repeated render requests follow an agreed stop policy.

The release decision goes beyond the four edits.

Unchanged connections still carry new behavior: FAILED triggers another render POST; a nonmatching completion response loops through Wait1. Before sign-off, establish the provider contract, item pairing and bounded rerender/polling policy, then verify the final upload. The 22-node set is static reachability, not observed runtime impact.

Before: 5b4f23c → After: 7cd32c2 · Migration commit · Full analysis. Fixtures omit pinned data and export-instance metadata; credential/webhook identifiers are replaced consistently. Original node IDs, parameters and graph are retained.

02 / Requests & completion

Prove the contract at the boundary.

Use controlled response fixtures in the target n8n environment. Capture evaluated values and branch outputs; attach evidence by case ID. Confirm the intended provider contract before accepting a payload.

Client / release owner: ______________________Environment / n8n version: __________________

API-1Video request shape

Not run

Input: preparingField.videoId = "fixture-video"; videoSource = "youtube".
Check: Evaluate the generateShorts JSON body. Require options.youtubeVideoId to contain the source ID, retain functionName: "VideoShorts" and the intended empty webhook. Confirm the provider accepts removal of videoSource.
Evidence: Evaluated request JSON, source-item reference and agreed provider schema / response evidence.

Owner: ________________ Evidence / run ID: ________________________Observation / outcome: ___________________________________________________

API-2Two-item ID and styling pairing

Not run

Input: Two current-item fixtures with ['data.shorts'].id values 42 and 43, each with a distinct styling object.
Check: Capture one renderShort body per item. Each shortId must come from the corresponding current_item_ref['data.shorts'].id; renderOptions must preserve the intended type and fields. Reject cross-paired IDs or styling.
Evidence: Both evaluated bodies beside their originating item and styling fixtures.

Owner: ________________ Evidence / run ID: ________________________Observation / outcome: ___________________________________________________

API-3Serialization edge cases

Not run

Input: Styling as an object, preset string, missing value and malformed upstream text; include an ID with a string value.
Check: The new template interpolates styling directly; the old one used .toJsonString(). Evaluate each combination. Record JSON validity and provider-required types; specify which inputs are supported and how unsupported inputs stop.
Evidence: Input/output matrix with parsed JSON or exact error, plus the type decision for each case.

Owner: ________________ Evidence / run ID: ________________________Observation / outcome: ___________________________________________________

STATUS-1Completed work exits the loop

Not run

Input: Controlled status response: {"status":"COMPLETED"}.
Check: isError ? takes false, then iscompleted ? takes true. Continue to metadata generation without another render/poll cycle for that item.
Evidence: Branch trace, metadata input and per-item render/status request counts.

Owner: ________________ Evidence / run ID: ________________________Observation / outcome: ___________________________________________________

Keep credentials out of the evidence packet. Record a redacted evaluated body and an execution reference rather than a credential-bearing request.

03 / Failure, polling & delivery

Make the stopping rules explicit.

Establish the retry budget and timeout with the release owner. The exported graph shows cycles; it does not establish a safe runtime limit.

STATUS-2Repeated failure has a stopping rule

Not run

Input: Repeated controlled responses: {"status":"FAILED"}.
Check: isError ? takes true back to renderShort. Record POST count and item identity. Accept repeat requests only within the agreed retry/stop policy; demonstrate the terminal outcome.
Evidence: Per-item POST trace, configured retry/timeout controls and final stop / error record.

Owner: ________________ Evidence / run ID: ________________________Observation / outcome: ___________________________________________________

STATUS-3Polling progresses to completion

Not run

Input: {"status":"PENDING"}, then {"status":"COMPLETED"}. PENDING is a synthetic nonmatching value, not an asserted provider state.
Check: The first response takes the poll/wait path; the second exits it. Record elapsed wait and status-request count against the intended polling policy.
Evidence: Ordered response / branch trace, wait timing and request count for the same item.

Owner: ________________ Evidence / run ID: ________________________Observation / outcome: ___________________________________________________

STATUS-4Malformed and legacy responses terminate

Not run

Input: {}, {"status":null}, {"status":"completed"}, {"type":"done"}, {"type":"error"}.
Check: Record validation errors or nonmatching routes. Establish and verify the timeout/error outcome so these responses cannot lead to indefinite polling or unintended rerenders.
Evidence: One result per fixture: route or error, request count, elapsed time and terminal outcome.

Owner: ________________ Evidence / run ID: ________________________Observation / outcome: ___________________________________________________

OUTPUT-1The intended shorts reach delivery

Not run

Input: Two rendered-short fixtures with distinct IDs and controlled upload responses.
Check: Confirm output count, metadata-to-file pairing, scheduled publication data and one intended upload per short.
Evidence: Reconciliation of source short → rendered file → metadata/schedule → controlled upload result.

Owner: ________________ Evidence / run ID: ________________________Observation / outcome: ___________________________________________________

Release decision · Pending execution evidence

Retry / timeout policy: ________________________________________________________

Decision (proceed / hold / revise): ______________ Open issues: __________________

Release owner: __________________ Reviewer: __________________ Date: __________

04 / Separately scoped executed-checks example

Two failures. One targeted revision.

Recommended next step: revise the render payload, then complete target-environment acceptance before rollout. The original expression failed on object-valued styling and on the retry path.

Executed 5 Oct 2026 · n8n 2.41.7 / Node.js 26.10.0. A loopback-only Linux network namespace hosted n8n and a local HTTP mock. Render fixtures use two shorts, numeric IDs 42 and 43, with distinct styling.

Tested slice: original render-loop nodes, expressions and wiring, with synthetic input and service responses, shortened waits, and a terminal recorder replacing metadata and upload. Results below cover that isolated slice; the eight full-workflow cases on pages 2–3 remain Not run.

Observed requests and outcomes · request totals per scenario
Payload / response fixture	POST / GET	Observed result
Original · object stylingImmediate completion	0 / 0	Fail · first request blocked`[object Object]` makes the JSON body invalid.
Original · JSON-encoded stylingFailed → replacement	1 / 1	Fail · retry body invalidThe status-response input supplies no `styling`; execution stops at the second render attempt.
Revised · object stylingImmediate completion	2 / 2	Pass · 2 terminal outputsIDs and styling stay paired.
Revised · object stylingPending → completion	2 / 4	Pass · 2 terminal outputsEach short completes after polling.
Revised · object stylingFailed → replacement → completion	4 / 4	Pass · 2 terminal outputsTwo render attempts per short; IDs and styling stay paired.

Adopt this field revision for the next test run

Set renderShort.parameters.jsonBody to an object expression. Read both fields from the paired source item on initial and retry executions:

={{ {
  shortId: $('current_item_ref').item.json['data.shorts'].id,
  renderOptions: $('current_item_ref').item.json.styling
} }}

Before rollout · complete these three acceptance steps

Agree the provider contract: validate the generate/render payloads and supported ID/styling types against the target API.
Bound recovery: agree rerender limits and polling timeouts, then test repeated failure and malformed responses through their terminal outcomes.
Verify delivery: run the complete workflow and reconcile both short IDs through metadata, scheduling and the intended uploads.

Full eight-scenario result record · Reproduce the checks and inspect adaptations · Historical workflow: MI, MIT (source and license on page 1).

A small API migration.A complete handoff.

What changes for this release

01 · Generate shorts

02 · Render each item

03 · Recognize completion

04 · Handle failure

The release decision goes beyond the four edits.

Prove the contract at the boundary.

API-1Video request shape

API-2Two-item ID and styling pairing

API-3Serialization edge cases

STATUS-1Completed work exits the loop

Make the stopping rules explicit.

STATUS-2Repeated failure has a stopping rule

STATUS-3Polling progresses to completion

STATUS-4Malformed and legacy responses terminate

OUTPUT-1The intended shorts reach delivery

Release decision · Pending execution evidence

Two failures. One targeted revision.

Adopt this field revision for the next test run

Before rollout · complete these three acceptance steps

A small API migration.
A complete handoff.