Course lesson 34 · Building AI Workflows
Update: Fixing issues with 1MiB Output limit
This corrective lesson fixes workflow failures caused by oversized persisted step output, especially after screenshots were added. The first step now creates the evaluation ID, renders the page, and writes bulky evidence directly to R2, returning only the text needed for AI and that ID. The AI step remains, and the final database save accepts the already-created ID rather than generating its own.
Primary source: course video 34 · Supplied English subtitles · 00:02:52.
Understand the idea
- A workflow step’s returned value is persisted state, so its size matters independently of whether the rendering operation succeeded.
- The recording’s failure concerns a 1 MiB allowed output size; screenshots can make the earlier return object exceed it.
- Large artifacts belong in object storage, while small values or references cross workflow step boundaries.
- Creating the evaluation ID before storage lets R2 keys and the later D1 record share the same identity.
- Moving work into a step changes the checkpoint boundary without changing the application’s overall purpose.
What the course does
- Identify the first collection step as the source of the oversized saved-state error.
- Generate an evaluation ID at the start of that step.
- Render the destination and move the HTML, text, and screenshot R2 writes into the same step.
- Return the evaluation ID and body text instead of the full HTML and encoded image.
- Keep the AI step using the returned text.
- Change the add-evaluation query to accept the caller’s ID, save the database record last, and remove the separate final R2 step.
Watch for
- This patch supersedes the earlier four-step implementation; later videos may still show the pre-patch ordering.
- The instructor expects text to be small, but explicitly notes that it too could be stored and retrieved from R2 if necessary.
- Added advice: measure serialized byte size rather than assuming a page is small, and consider references for every potentially large result.
Recall before revealing
Why does moving the R2 upload into the first step fix the screenshot-related failure?
Reveal the explanation
The large screenshot no longer has to be returned and persisted as that step’s output; it is stored in R2 before the checkpoint.
Try it
Redraw the final workflow after this patch and annotate which data is stored in R2 versus returned between steps.
Check your result
Your diagram shows collection plus backup first, AI second, database save last, with a shared ID and no large image crossing a step boundary.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Rewatch only what you need
Open this lesson in your original course library and seek to the times below. Videos are not hosted on this site.
- 00:00:04 — Student-reported maximum-output-size error
- 00:00:36 — Step result persisted as workflow state
- 00:01:09 — Moving R2 writes into the collection step
- 00:01:38 — Returning only text and evaluation identity
- 00:02:25 — Database query now accepts the existing ID
Companion primary documentation: Workflows limits. For recorded API names, commands, limits, and prices, check the version you use.