fix: display llm robot create on reload or tab switch

[amhsirak]

Previously, the creation state of an LLM robot was stored only in memory, causing the creation placeholder to disappear if the page was reloaded or the user switched tabs during creation.

This PR persists the robot in the database with a creating state, ensuring the creation placeholder remains visible until the robot is fully created.

Summary by CodeRabbit

• New Features

  • Added real-time status tracking and automatic polling for recordings in the creation state, refreshing every 8 seconds for improved visibility.

• Refactor

  • Optimized robot creation workflow for better responsiveness during setup.

[coderabbitai]

Walkthrough

The PR adds a creating status discriminator to robot metadata, refactors LLM robot creation into a two-phase process that immediately creates a stub marked as creating and later updates it to ready once workflow generation succeeds, and implements client-side polling that refetches every 8 seconds while any recording exhibits creating status.

Changes

Creating status workflow for LLM robots

Layer / File(s)	Summary
Creating status type definition server/src/models/Robot.ts	RobotMeta is extended with an optional status field typed as 'creating' | 'ready' | 'failed', enabling status transitions in robot metadata.
Two-phase LLM robot creation flow server/src/routes/storage.ts	Robot creation route now creates a stub robot with status: 'creating' and empty workflow before generating the workflow, then generates the workflow via WorkflowEnricher, validates success, updates the stub with normalized workflow/pairs/url and sets status: 'ready', or destroys the stub and returns 400 on failure.
Polling and loading state for creating recordings src/components/robot/RecordingsTable.tsx	useRef is added to imports; row isLoading now also activates on recording_meta.status === 'creating'; a useEffect using pollingRef starts an 8-second refetch() interval when any creating recording is detected and clears it on dependency change or unmount.

Sequence Diagram

sequenceDiagram
  participant Client
  participant CreateRoute as CreateRobotRoute
  participant RobotDB as Robot DB
  participant Enricher as WorkflowEnricher

  Client->>CreateRoute: POST LLM robot creation
  CreateRoute->>RobotDB: create stub<br/>(status=creating)
  CreateRoute->>Enricher: generateWorkflow
  Enricher-->>CreateRoute: workflow result
  alt workflow success
    CreateRoute->>RobotDB: update stub<br/>(status=ready, url, pairs)
    CreateRoute-->>Client: return ready robot
  else workflow failure
    CreateRoute->>RobotDB: destroy stub
    CreateRoute-->>Client: 400 error
  end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• getmaxun/maxun#425: Modifies RecordingsTable.tsx loading-state behavior (isLoading logic), directly connected to the new per-row isLoading activation on recording_meta.status === 'creating'.
• getmaxun/maxun#921: Modifies RecordingsTable.tsx and storage.ts LLM robot creation flow to drive loading UI from recording_meta.status, providing foundational creating-state detection that this PR builds upon with polling.
• getmaxun/maxun#946: Introduces generateWorkflowFromPromptWithSearch and optional-URL workflow routing in WorkflowEnricher, which the two-phase creation flow in this PR directly invokes during the workflow-generation phase.

🐇 A stub is born with status creating,
Workflow enrichment—the route's great making!
Update to ready when all checks pass,
The UI polls with style and class,
Until the robot's workflow is set fast! ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title is partially related to the changeset but emphasizes the user-facing symptom (persistence across reload/tab switch) rather than the main technical implementation (two-phase creation with database stub). The changeset's core change is refactoring the creation flow to persist robot state in the database, which the title alludes to indirectly but does not clearly articulate.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch llm-rob-create

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

server/src/routes/storage.ts (1)

792-795: 💤 Low value

Add warning log when stub cleanup fails.

Silently swallowing the destroy error makes debugging harder if cleanup consistently fails. Consider logging a warning before rethrowing the original error.

💡 Suggested improvement

     } catch (llmError) {
-      try { await stubRobot.destroy(); } catch (_) {}
+      try { await stubRobot.destroy(); } catch (cleanupErr) {
+        logger.log('warn', `Failed to cleanup stub robot ${stubRobot.id} after LLM error: ${cleanupErr}`);
+      }
       throw llmError;
     }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@server/src/routes/storage.ts` around lines 792 - 795, In the catch block that
handles the stubRobot.destroy() error (the inner try-catch where the error is
currently being silently swallowed), add a warning log statement that captures
and logs the destroy error before swallowing it. This will help with debugging
if cleanup consistently fails while still preserving the original llmError being
rethrown. Update the empty catch handler to log the destroy failure with
appropriate context before continuing with the error handling flow.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@server/src/routes/storage.ts`:
- Around line 792-795: In the catch block that handles the stubRobot.destroy()
error (the inner try-catch where the error is currently being silently
swallowed), add a warning log statement that captures and logs the destroy error
before swallowing it. This will help with debugging if cleanup consistently
fails while still preserving the original llmError being rethrown. Update the
empty catch handler to log the destroy failure with appropriate context before
continuing with the error handling flow.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 44224c54-1437-4133-8dca-b54418c9dedc

📥 Commits

Reviewing files that changed from the base of the PR and between 031c1fb and 38d66dd.

📒 Files selected for processing (2)

• server/src/models/Robot.ts
• server/src/routes/storage.ts

✅ Files skipped from review due to trivial changes (1)

• server/src/models/Robot.ts