Skip to content

Conversation

@bfollington
Copy link
Contributor

@bfollington bfollington commented Nov 6, 2025

  • fix(compiler): Wait for charm initialization before navigating
  • fix(compiler): Reuse compileAndRun result instead of creating new action
  • Copy across cancellation pattern from llm.ts
  • Move compiler.tsx to patterns package

Summary by cubic

Restored the compileAndRun example and fixed navigation by waiting for the compiled result. Adds cancellation and request dedupe so stale compilations don’t update state.

  • Bug Fixes

    • Navigate only after result is ready; prevents “blackhole” clicks.
    • Reuse the existing compileAndRun result; avoids double runs.
    • Show the actual compiler error in the UI.
  • Refactors

    • Add AbortController cancellation and requestId dedupe in compile-and-run.
    • Move compiler.tsx into the patterns package.
    • Add a simple edit handler to update the code cell.

Written for commit 679e741. Summary will update automatically on new commits.

claude and others added 4 commits November 6, 2025 01:22
The issue was that navigateTo was being called immediately with the result
from compileAndRun, but the result Cell is initially undefined and only gets
populated asynchronously after compilation completes.

Solution follows the same pattern used in chatbot-list-view.tsx:
- Use a lift to monitor the result Cell reactively
- Only navigate once the result is populated (not undefined)
- Use an isNavigated flag to ensure navigation only happens once

Changes:
- Add navigateWhenReady lift that waits for result to be ready
- Update visit handler to use the lift instead of calling navigateTo directly
- Show actual error messages in the UI instead of generic "fix the errors"

This fixes the "blackhole" issue where navigateTo appeared to do nothing.
The previous approach called compileAndRun inside the handler, which:
- Created a NEW compileAndRun action on every handler invocation
- Caused double invocation due to re-renders from pending state changes
- Hit the run index check at compile-and-run.ts:191 and bailed early

Solution:
- Call compileAndRun once in the recipe body (already done for error display)
- Reuse the stable result cell from that single compileAndRun call
- Handler just calls navigateTo(result) on the existing cell
- navigateTo is an Action, so it re-runs when result populates

This is much simpler and avoids the double invocation issue entirely.
No need for the navigateWhenReady lift workaround!
Copy link
Contributor

@cubic-dev-ai cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 issue found across 2 files

Prompt for AI agents (all 1 issues)

Understand the root cause of the following 1 issues and fix them.


<file name="packages/runner/src/builtins/compile-and-run.ts">

<violation number="1" location="packages/runner/src/builtins/compile-and-run.ts:179">
When the recipe is cancelled, this guard sees the aborted signal and returns before clearing the pending cell, so the compile action stays stuck in pending=true even though it has stopped. Please allow pending to be reset after cancellation.</violation>
</file>

React with 👍 or 👎 to teach cubic. Mention @cubic-dev-ai to give feedback, ask questions, or re-run the review.

if (thisRun !== currentRun) return;
// Only process this error if the request hasn't been superseded
if (requestId !== thisRequestId) return;
if (abortController?.signal.aborted) return;
Copy link
Contributor

@cubic-dev-ai cubic-dev-ai bot Nov 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When the recipe is cancelled, this guard sees the aborted signal and returns before clearing the pending cell, so the compile action stays stuck in pending=true even though it has stopped. Please allow pending to be reset after cancellation.

Prompt for AI agents
Address the following comment on packages/runner/src/builtins/compile-and-run.ts at line 179:

<comment>When the recipe is cancelled, this guard sees the aborted signal and returns before clearing the pending cell, so the compile action stays stuck in pending=true even though it has stopped. Please allow pending to be reset after cancellation.</comment>

<file context>
@@ -156,10 +168,15 @@ export function compileAndRun(
-          if (thisRun !== currentRun) return;
+          // Only process this error if the request hasn&#39;t been superseded
+          if (requestId !== thisRequestId) return;
+          if (abortController?.signal.aborted) return;
 
           runtime.editWithRetry((asyncTx) =&gt; {
</file context>
Fix with Cubic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants