Render Tutorials
Stock research that survives a closed browser

What you'll build

⏱ 3 min

Imagine you ask an app to research a company. You type a ticker, hit go, and wait. A spinner spins. If you stay, a memo appears. If you close the tab halfway through, what happens to that research?

In most simple apps, it is gone. Not because the computer forgot how to think, but because the work was tied to the open page. Leave, and there is no ticket number, no status to check, nothing to reopen.

That is the whole lesson of this tutorial in one picture: work that only lives while you watch it cannot be recovered when you stop watching.

You will use a small stock-research app to feel that. It takes a ticker like NVDA, gathers some facts (mock data, so nothing fancy to set up), and writes a short memo. Later you wrap those steps as Workflow tasks (one root task, several step tasks) so you can start research, walk away, come back, and still find the result by the root task-run ID.

Work that outlives the request

Plenty of software starts work that people leave mid-flight:

  • Agents
  • Report generation
  • Enrichment

The first version almost always ties that work to the open request: accept input, await every step, return the result. That path is short, and it feels fine while one person stays connected.

Real usage does not stay connected:

  • A phone backgrounds the app
  • An API times out and retries
  • Someone starts on a laptop and checks again from another device, or comes back tomorrow

Without a run you can find later, the product cannot tell whether work is still going, finished, duplicated, or never started.

The stock research app in this tutorial is a stand-in for that class of work. Closing a tab is how you feel the missing receipt.

What you will do

  1. Join the Render Atlanta workshop workspace (form)
  2. Deploy the starter
  3. Feel the broken close-tab run
  4. Clone the fork and wrap the research steps as Workflow tasks (one root task, several step tasks)
  5. Create the workflow service, wire the web service, confirm the root task-run ID
  6. Recover the memo after a reload using that root ID

The mock research steps stay the same. You wrap them as tasks, and a root task-run ID becomes the receipt.

Before: request-owned

flowchart LR
  b1["Client"] --> p1["POST awaits researchStock"] --> x1["Connection ends → unreachable"]

After: owned by a task run

flowchart LR
  b2["Client"] --> s1["startTask root researchStock"]
  s1 --> id1["root task-run ID"]
  s1 --> w1["Workflow: step tasks under root"]
  id1 --> r1["Poll / recover by root ID"]
  w1 --> r1

The UI stores only the root task-run ID. Step-task runs can appear in the Dashboard; the browser does not need their IDs.

What is the main change this tutorial makes?

What you learned

  • Long-running work needs an identity outside the request
  • You will recover by the root task-run ID (the receipt)
  • Next: fork and deploy the starter