[sgardoll]

Findings addressed

G1 — Greptile P1, "Gateway errors hide uncertain writes" (src/provisionStream.js:177-179):

If a gateway returns 502 after forwarding the provisioning request but before delivering the runner's result, this code treats it as proof that nothing was written. The runner may still be deploying classes, yet the UI reports failure and keeps the cached project snapshot; a retry can provision those classes again. [Unknown remote outcomes must remain unconfirmed and require reconciliation before retrying.]

Fixed in deployOutcomeOfStreamResult: only a 4xx is still a definitive pre-write refusal (FAILED). Every 5xx is now UNCONFIRMED — a gateway can answer 502/503/504 after the request reached the runner. The caller's existing UNCONFIRMED path then invalidates the project-source cache and marks the files dirty (markProjectSourceDirty), so a retry must re-export and cannot silently re-provision.

G2 — Greptile P1, "Repeated exports clear pending writes" (app.js:3086-3089):

After a confirmed retry writes the same file content, one export uses its verified credit. A second export of that unchanged content then clears the earlier uncertain write, even if its request is still running. The snapshot can be cached, and a later write from the first request can leave the next deploy planning against stale files.

Fixed in resolveProjectPubspec's dirty-sighting loop: an export sighting that consumes a verified credit is marked explainedByVerified on the record. A later export of the same unchanged content is the same fact, not a new landing, so it can no longer retire the uncertain credit. The uncertain write is resolved only by its own late result (success → converts to a verified credit consumed by the next sighting; provable pre-write failure → retired), so the snapshot stays uncached while the write may still land.

D1 — Devin, "Previous deploy hides active progress" (app.js:6744-6746):

When another deploy starts within one second, the prior commitStateChange timer closes its active progress overlay. The remote write continues without a protected progress view.

Fixed in the commitStateChange listener: the terminal state's 1s hide timer is now tracked in commitProgressHideTimer and cleared when a new deploy reports PREPARING/VALIDATING/PUSHING, so a stale timer can no longer close the new deploy's overlay.

Fail → pass evidence (base head 6dd8edb)

The source files (app.js, src/provisionStream.js) were reverted to base head while the new tests were kept; the same commands were then re-run on the fixed head. No other files differ.

Base head — unit:

$ CI=1 npm test
not ok 295 - a 5xx server error with no streamed result is UNCONFIRMED — a gateway can fail after forwarding
# tests 355
# pass 354
# fail 1

Base head — e2e (--retries=0):

$ CI=1 CCC_TEST_PORT=3104 npx playwright test e2e/stu380-deploy.spec.js \
    -g "gateway 502 keeps|identical retry's success|new deploy within the terminal hide"
  ✘ 1 … a new deploy within the terminal hide delay keeps its progress overlay
      Error: expect(locator).toHaveClass(expected) failed
      Expected pattern: /\bopen\b/
      Received string:  "modal-overlay"          ← stale timer removed .open
  ✘ 2 … a gateway 502 keeps the project snapshot dirty instead of reporting a refusal
      Expected: "UnconfirmedDeployError"
      Received: "Error"                          ← base called it a definitive refusal
  ✘ 3 … an identical retry's success cannot retire the earlier uncertain write
      Expected: 4
      Received: 3                                ← base cached the snapshot on the unchanged sighting
  3 failed

Fixed head b7830b8:

$ CI=1 npm test
# tests 355
# pass 355
# fail 0

$ CI=1 CCC_TEST_PORT=3104 npx playwright test e2e/stu380-deploy.spec.js \
    -g "gateway 502 keeps|identical retry's success|new deploy within the terminal hide"
  ✓ 1 … a new deploy within the terminal hide delay keeps its progress overlay
  ✓ 2 … a gateway 502 keeps the project snapshot dirty instead of reporting a refusal
  ✓ 3 … an identical retry's success cannot retire the earlier uncertain write
  3 passed

The break each test catches:

• G1 unit test: reverting deployOutcomeOfStreamResult to FAILED for all httpRejected fails the test (observed above).
• G1 e2e: the 502 must produce UnconfirmedDeployError and force a fresh export (exportCalls 1→2); base throws a plain Error and leaves the cached snapshot.
• G2 e2e: the second sighting of unchanged content must not cache (exportCalls 4, not 3); a late success from the first attempt then resolves it and caching resumes at 5.
• D1 e2e: after SUCCESS + a new PREPARING inside the hide delay, #commit-progress-overlay still carries .open past the 1s timer and 0.25s visibility transition.

CI results on pushed head b7830b8

Command	Result
CI=1 npm test	355 passed / 0 failed
CI=1 npm run build	✓ built
CI=1 CCC_TEST_PORT=3104 npm run test:ui	208 tests: 207 passed + 1 flaky on retry (stu389-hero-mark-field WebGL timing, unrelated; passes 3/3 in isolation with --retries=0 --repeat-each=3)
CI=1 npm run test:accessibility	7 shells passed
CI=1 npm run test:deploy-guard	9/9 passed
CI=1 npm run test:proxies	30/30 passed
CI=1 python3 scripts/scan_bundle_for_leaks.py	clean

Functions edited (line ranges are post-change)

• app.js resolveProjectPubspec — dirty-sighting loop at lines 3080-3104; and the projectSourceDirtyWrites model comment at lines 2673-2684 (same bookkeeping feature).
• app.js DOMContentLoaded callback's commitStateChange listener — lines 6738-6772 (timer declaration + listener).
• src/provisionStream.js deployOutcomeOfStreamResult — lines 148-190; httpRejected comment in readProvisionResponse — lines 93-104.
• Tests: src/provisionStream.test.js (two tests updated/added), e2e/stu380-deploy.spec.js (one new G1 test, one new D1 test, G2 test extended).

No other region of app.js was touched. git status after restoring generated artifacts shows only these four files modified.

Not implemented / out of scope

• The 5xx UNCONFIRMED message text in provisionMissingCodeFiles (app.js ~2940) is outside this brief's ownership. A gateway 502 now surfaces the existing unconfirmed wording ("connection … dropped before it reported a result … may still be finishing … reconcile before retrying"), which does not claim nothing was written, but it does not name the HTTP status.
• src/deployOutcome.js was not touched: its FAILED doc already states that 5xx are UNCONFIRMED, which the fix now honours.
• No mechanism retires an uncertain credit when an attempt never reports any result; by design the snapshot stays uncached for the session rather than caching a snapshot that ignores a possibly-written file.

Judgement calls / uncertainties

• All 5xx, not just 502/503/504, classify as UNCONFIRMED: none of them proves the request was turned away before a write, and the codebase's stated rule is that unknown remote outcomes stay unconfirmed.
• explainedByVerified is deliberately conservative: once a verified write has explained a content sighting, repeated sightings of that content can never retire the uncertain credit — even if the content later changes away and back. Only the attempt's own result resolves it.
• The D1 test asserts the .open class rather than computed visibility because the overlay's visibility transition (0.25s) is still mid-flight at the 1s hide-delay boundary; the class is the settled evidence that the timer ran.

[greptile-apps]

This PR does not match any of the 1 configured review trigger rule.

[devin-ai-integration]

Devin Review found 2 new potential issues.

[devin-ai-integration]

🔴 Repeated exports erase pending retries

When two identical provisions remain unconfirmed, resolveProjectPubspec retires both after repeated exports show one landing. The unchanged content consumes an uncertain credit on every export, so a later retry can overwrite a newer edit behind a cached snapshot.

Learn more

Provisioning attempts that time out stay tracked as uncertain because the runner can still write after the browser stops waiting. markProjectSourceDirty increments the uncertain count for every attempt, including retries of the same file content. If two such attempts exist, a single remote write produces one observable content transition. Every fresh export of that unchanged content then decrements the count again, even though the other attempt can still run. resolveProjectPubspec caches the export once the count reaches zero, hiding a later write from subsequent deploy planning.

Example: Attempts A and B both time out while provisioning gauge_model.dart with content X. A writes X; two exports showing X clear both credits. A new edit Y is deployed, but B later writes X, and a subsequent deploy reads the cached snapshot instead of X.

Recommended fix: Track whether an observed path/content transition has already been used to retire an uncertain attempt, not only whether a verified write explained it. Allow another retirement only after a distinct observable transition or a definitive late result for that attempt. Preserve the existing verified credit handling for confirmed retries.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔍 Gateway errors retain timeout wording

An immediate HTTP 502 now reports its status, but showCommitUnconfirmedModal still says the browser stopped waiting. The terminal title reads like a timeout despite a received response.

---

Was this helpful? React with 👍 or 👎 to provide feedback.