[waleedlatif1]

Summary

• When Turbopack panics on a restored dev cache, desktop-live already empties the cache in its exit trap, but a sticky disk keeps nothing from a job with a failed step, so the clear is discarded and every later run restores the same broken cache and fails the same way
• desktop-live now writes a turbopack-cache-broken marker (the Next version) into its uploaded results when the cache broke
• New desktop-live-cache-reset job runs only after a failed desktop-live, reads the marker, mounts that dev cache and empties it in a passing job, so the empty cache is what the next run mounts
• The key is rebuilt from the run's own event and fork context; the marker only supplies the Next version (validated), so a fork's marker can't name any cache but its own
• A desktop-live failure the cache didn't cause leaves no marker and keeps the warm cache
• Not in ci's needs: it's maintenance, not a gate

Type of Change

• Bug fix

Testing

• actionlint on checks.yml: no new findings (the one finding is pre-existing on staging)
• Ran the key-resolution step locally against good (16.4.0, 16.5.0-canary.3), hostile (path-like, space-injected, empty) and missing markers: rebuilt key matches the live cache key; hostile markers fail without emitting a key
• End-to-end proof is the first staging push after merge: the broken push cache fails desktop-live once, the reset job empties it, and the next run goes green

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing (new tests pass the test-audit authoring gate)
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
docs	Ready	Preview	Oct 21, 2026 6:51am UTC

[cubic-dev-ai]

1 issue found across 1 file

Confidence score: 3/5

• In .github/workflows/checks.yml, startup recovery truncates next_log and loses the marker, so finish may not recognize a later test failure. Preserve the marker in a cache_broken_seen flag and use it in finish.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name=".github/workflows/checks.yml">

<violation number="1" location=".github/workflows/checks.yml:496">
P2: The marker is lost when startup recovery clears and truncates `next_log`, then a later test failure occurs. Preserve a `cache_broken_seen` flag before truncating the log and use that flag in `finish`, otherwise the failed job can leave the same broken sticky cache for the next run.</violation>
</file>

<sub>Heads up: you’re close to your flex budget. Increase your flex budget so reviews don’t pause.

Turn on auto-fix | Re-trigger cubic</sub>

[greptile-apps]

Confidence Score: 5/5

[Low impact] The PR appears safe to merge.

Summary

The PR lets a passing maintenance job clear a broken desktop-live cache after a failed test job.

• A separate job clears the desktop cache after a Turbopack panic.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[desktop-live fails] --> B[Download results]
  B --> C{Broken-cache marker present?}
  C -->|No| D[Keep warm cache]
  C -->|Yes| E[Check version and rebuild cache key]
  E --> F[Mount cache]
  F --> G[Create directory if missing]
  G --> H[Empty cache in passing job]

Loading

_{Reviews (4) · Last reviewed commit: "fix(ci): create the dev cache path befor..." · Reviewed by Greptile}

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

All reported issues were addressed across 1 file

<sub>Heads up: you’re close to your flex budget. Increase your flex budget so reviews don’t pause.

Turn on auto-fix | Re-trigger cubic</sub>

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

1 issue found across 2 files

Confidence score: 3/5

• In .github/workflows/checks.yml, the reset can erase the shared sticky disk while another desktop-live run is writing it, and that writer can repopulate the cache afterward. Coordinate the reset and writes across refs that share this cache key.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name=".github/workflows/checks.yml">

<violation number="1" location=".github/workflows/checks.yml:607">
P2: This reset can erase a shared sticky disk while another `desktop-live` run is writing it. Because the key omits the ref but CI concurrency is per ref, a later writer can repopulate the broken cache and defeat this reset; coordinate writers for this cache key.</violation>
</file>

<sub>Heads up: you’re close to your flex budget. Increase your flex budget so reviews don’t pause.

Turn on auto-fix | Re-trigger cubic</sub>

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 2 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

<sub>Heads up: you’re close to your flex budget. Increase your flex budget so reviews don’t pause.

Turn on auto-fix | Re-trigger cubic</sub>