Test 088 for Morgan Chen

Request

Email support@scaffold.dev a customer-safe description of what the February 14, 2024 Mercury timeout-recovery deploy changed, distinguishing the UI fixes from underlying system changes.

Required memory

Fact 176

The February 14, 2024 Mercury deploy shipped MER-1749, which narrowed the reconcile path so retry status refreshes correctly after timeout recovery without requiring a page reload.

Source evidence (1)

001020Feb 14, 2024 / 10:39 UTC-08:00

Leo says the Mercury live-sync support fix is actually green now. [Discord DM — Leo Park → Morgan Chen — Wed Feb 14, 2024 10:26 AM PT] Mercury live-sync follow-up deploy is green. Deploy / verification - deploy completed cleanly at 10:14 PT - post-deploy smoke on the current timeout-recovery path is green - bounded timeout replay is green after deploy - no duplicate sync jobs seen in logs during replay - alerting flat through the first 10+ min after push What shipped - MER-1749: narrowed reconcile path so retry status refreshes correctly after timeout recovery without a page reload - MER-1823: stale timeout banner now clears after a successful retry in the same session Customer-impact summary - This is the support/trust edge Jake flagged from the two current Mercury workspaces: the retry actually ran, but stale pending state plus the old timeout banner made the operator think recovery had failed until they refreshed - After the deploy, the recovery surface is now updating in-session the way support expected, so the user can see the recovered state without the extra refresh / reopen step - This should cut the "did it actually run or is it still stuck" support loop on the current live-sync path Boundaries - no sync-engine change - no retry-policy change - no auth/admin-role change - no SSO, audit-history, admin-versus-billing-owner, or other enterprise-readiness work bundled in Proposed #eng-releases note if useful: "Mercury live-sync follow-up is now live. This deploy includes two scoped UI fixes in the timeout-recovery path: retry status now refreshes correctly after timeout recovery without a page reload, and stale timeout messaging clears after a successful retry in the same session. No sync-engine or retry-policy change is part of this deploy." If you want, I can also attach the replay/log refs to MER-1279 and close the two support cases from the product side. Please post a concise Discord note to #eng-releases. Keep it to the two scoped timeout-recovery UI fixes and the support/trust impact. Explicitly do not make it sound like sync-engine, retry-policy, auth/admin-role, SSO, audit-history, admin/billing-owner, or broader enterprise-readiness work shipped.

Message 001020 in history

Fact 177

The February 14, 2024 Mercury deploy shipped MER-1823, which makes a stale timeout banner clear after a successful retry in the same session.

Source evidence (1)

001020Feb 14, 2024 / 10:39 UTC-08:00

Leo says the Mercury live-sync support fix is actually green now. [Discord DM — Leo Park → Morgan Chen — Wed Feb 14, 2024 10:26 AM PT] Mercury live-sync follow-up deploy is green. Deploy / verification - deploy completed cleanly at 10:14 PT - post-deploy smoke on the current timeout-recovery path is green - bounded timeout replay is green after deploy - no duplicate sync jobs seen in logs during replay - alerting flat through the first 10+ min after push What shipped - MER-1749: narrowed reconcile path so retry status refreshes correctly after timeout recovery without a page reload - MER-1823: stale timeout banner now clears after a successful retry in the same session Customer-impact summary - This is the support/trust edge Jake flagged from the two current Mercury workspaces: the retry actually ran, but stale pending state plus the old timeout banner made the operator think recovery had failed until they refreshed - After the deploy, the recovery surface is now updating in-session the way support expected, so the user can see the recovered state without the extra refresh / reopen step - This should cut the "did it actually run or is it still stuck" support loop on the current live-sync path Boundaries - no sync-engine change - no retry-policy change - no auth/admin-role change - no SSO, audit-history, admin-versus-billing-owner, or other enterprise-readiness work bundled in Proposed #eng-releases note if useful: "Mercury live-sync follow-up is now live. This deploy includes two scoped UI fixes in the timeout-recovery path: retry status now refreshes correctly after timeout recovery without a page reload, and stale timeout messaging clears after a successful retry in the same session. No sync-engine or retry-policy change is part of this deploy." If you want, I can also attach the replay/log refs to MER-1279 and close the two support cases from the product side. Please post a concise Discord note to #eng-releases. Keep it to the two scoped timeout-recovery UI fixes and the support/trust impact. Explicitly do not make it sound like sync-engine, retry-policy, auth/admin-role, SSO, audit-history, admin/billing-owner, or broader enterprise-readiness work shipped.

Message 001020 in history

Fact 175

The February 14, 2024 Mercury deploy included no sync-engine, retry-policy, auth/admin-role, SSO, audit-history, admin-versus-billing-owner, or other enterprise-readiness changes.

Source evidence (1)

001020Feb 14, 2024 / 10:39 UTC-08:00

Leo says the Mercury live-sync support fix is actually green now. [Discord DM — Leo Park → Morgan Chen — Wed Feb 14, 2024 10:26 AM PT] Mercury live-sync follow-up deploy is green. Deploy / verification - deploy completed cleanly at 10:14 PT - post-deploy smoke on the current timeout-recovery path is green - bounded timeout replay is green after deploy - no duplicate sync jobs seen in logs during replay - alerting flat through the first 10+ min after push What shipped - MER-1749: narrowed reconcile path so retry status refreshes correctly after timeout recovery without a page reload - MER-1823: stale timeout banner now clears after a successful retry in the same session Customer-impact summary - This is the support/trust edge Jake flagged from the two current Mercury workspaces: the retry actually ran, but stale pending state plus the old timeout banner made the operator think recovery had failed until they refreshed - After the deploy, the recovery surface is now updating in-session the way support expected, so the user can see the recovered state without the extra refresh / reopen step - This should cut the "did it actually run or is it still stuck" support loop on the current live-sync path Boundaries - no sync-engine change - no retry-policy change - no auth/admin-role change - no SSO, audit-history, admin-versus-billing-owner, or other enterprise-readiness work bundled in Proposed #eng-releases note if useful: "Mercury live-sync follow-up is now live. This deploy includes two scoped UI fixes in the timeout-recovery path: retry status now refreshes correctly after timeout recovery without a page reload, and stale timeout messaging clears after a successful retry in the same session. No sync-engine or retry-policy change is part of this deploy." If you want, I can also attach the replay/log refs to MER-1279 and close the two support cases from the product side. Please post a concise Discord note to #eng-releases. Keep it to the two scoped timeout-recovery UI fixes and the support/trust impact. Explicitly do not make it sound like sync-engine, retry-policy, auth/admin-role, SSO, audit-history, admin/billing-owner, or broader enterprise-readiness work shipped.

Message 001020 in history

Expected tool calls

send_email

Grading

1. field_equals / send_email

{
  "type": "field_equals",
  "tool": "send_email",
  "path": "result.ok",
  "value": true,
  "check_id": "morgan_088_00",
  "action_id": "morgan_088_send_email"
}

2. field_equals / send_email

{
  "type": "field_equals",
  "path": "result.to",
  "value": "support@scaffold.dev",
  "tool": "send_email",
  "check_id": "morgan_088_01",
  "action_id": "morgan_088_send_email"
}

3. field_llm_judge / send_email

{
  "type": "field_llm_judge",
  "path": "result.body",
  "criterion": "Describes retry status refreshing after timeout recovery without a page reload and stale timeout messaging clearing after successful retry in the same session. Keeps these scoped UI fixes separate from sync-engine, retry-policy, auth/admin-role or enterprise-readiness changes. Internal ticket IDs are optional in customer-safe wording; if given, MER-1749 is status refresh and MER-1823 is clearing stale messaging.",
  "tool": "send_email",
  "check_id": "morgan_088_02",
  "action_id": "morgan_088_send_email"
}

Complete grading specification

{
  "type": "tool_trace",
  "config": {
    "check_version": 2,
    "today": "2026-09-14",
    "assertions": [
      {
        "type": "field_equals",
        "tool": "send_email",
        "path": "result.ok",
        "value": true,
        "check_id": "morgan_088_00",
        "action_id": "morgan_088_send_email"
      },
      {
        "type": "field_equals",
        "path": "result.to",
        "value": "support@scaffold.dev",
        "tool": "send_email",
        "check_id": "morgan_088_01",
        "action_id": "morgan_088_send_email"
      },
      {
        "type": "field_llm_judge",
        "path": "result.body",
        "criterion": "Describes retry status refreshing after timeout recovery without a page reload and stale timeout messaging clearing after successful retry in the same session. Keeps these scoped UI fixes separate from sync-engine, retry-policy, auth/admin-role or enterprise-readiness changes. Internal ticket IDs are optional in customer-safe wording; if given, MER-1749 is status refresh and MER-1823 is clearing stale messaging.",
        "tool": "send_email",
        "check_id": "morgan_088_02",
        "action_id": "morgan_088_send_email"
      }
    ]
  }
}