Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

FableLoom shot autopilot sends the whole episode per call and times out on normal-size episodes; nothing is resumable

Open
  • Is something wrong?
#13,204 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
express, javascript
Domain
ai, backend

Research direction

Start with runEpisodeShotAutopilot in server/services/fableLoom/shots.js and trace the shot planning route, then compare how editorial autopilot starts runs and records runEvents. Map how draft and review results are stored and how provider timeouts reach the caller. Done means the stated acceptance criteria pass for a roughly 20-scene episode, including recovery after restart and stage, round, and provider details in timeout errors.

Written by the indexing model from the issue text.

Description

bug

Bug

Shot autopilot (POST /api/fableloom/:id/episodes/:episodeId/shots/plan, runEpisodeShotAutopilot in server/services/fableLoom/shots.js) sends the whole episode in one prompt per round, for both the draft stage and the review stage. On a moderately sized helper episode (~19 single-cut scenes, ~1.1k chars of teleplay each), a single call regularly takes longer than a provider's per-run timeout (300 s is common in providers.json).

What happens:

  • CLI run timed out after 300000ms → HTTP 500, after 10–24 minutes of wall time. Earlier rounds can finish before a later call times out.
  • Nothing is kept. Round output that passed isn't persisted, so every retry starts over.
  • A PortOS restart during the run (e.g. auto-update) ends the request with an empty reply, and there's no way to resume or poll it.

Proposed fix

  1. Chunk the work by dramatic group. Draft and review the shot split per outline scene (or a small window of adjacent scenes, plus a compact digest of the rest for context), then run one cheap whole-episode consistency pass over the plan JSON, not the teleplay. Each call stays well under the timeout and parallelizes.
  2. Run it as a background run, like editorial autopilot. Use start / status / cancel routes plus runEvents, so a long split doesn't depend on one held HTTP request and can be resumed after a restart.
  3. Persist per-round results (draft, review verdict, feedback), so a retry resumes from the last good round.
  4. Size-aware timeout: let the stage request a timeout that scales with prompt size (capped), or warn up front that the selected provider's timeout is likely too short for this episode size.
  5. Error message: name the stage and round that timed out (e.g. fableloom-shot-review round 2 timed out after 300 s on provider X) instead of the bare runner message.

Acceptance criteria

  • An episode of ~20 scenes with ~1k chars each completes a shot plan on a provider with a 300 s timeout.
  • Killing the server mid-run and restarting leaves the run resumable, or reported as failed with its completed rounds preserved, never silently lost.
  • A timeout error names the stage, round and provider.
Dominant language
JavaScript
Stars
38
Forks
32
Avg merge
36m
Merged PRs (30d)
989

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from atomantic/PortOS

All issues in atomantic/PortOS

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.