---
name: hermes-desktop-troubleshooting
description: Diagnose Hermes Desktop on Windows when something is broken or slow — update failures, plugin errors, backend not starting, app not launching, sudden response lag. Use when the user reports a Hermes Desktop error message, says "Hermes is broken" / "everything is taking forever", or shows a screenshot of an error dialog. Do NOT use for VPS-side hermes-gateway issues (use operating-hermes-gateway for those).
---

# Hermes Desktop Troubleshooting (Windows)

Hermes Desktop is an Electron app. "Backend update failed" and similar messages are usually misleading — the update itself often works, but a backend service (gateway, plugin, or python venv) failed to start, so the updater reports failure. Always check logs before assuming the updater is the problem.

## When to use this

- User shows screenshot/text of "Update didn't finish", "Backend update failed", or similar updater error
- User says Hermes is "broken", "won't start", "keeps crashing", or "plugin X is broken"
- Any Hermes Desktop error where the root cause isn't obvious

## Step 1: Check running processes

Multiple `Hermes.exe` processes are NORMAL — Electron is multi-process (main, renderer, gpu, utility, etc.). Expect 4-6. **Do not tell the user to kill them all unless there are clearly stale ones.**

```powershell
Get-Process | Where-Object {$_.Name -like "*hermes*"} | Select-Object Name, Id, StartTime | Format-Table -AutoSize
```

If anything is clearly orphaned (running for hours with no activity, or stuck after a crash), kill by PID:
```powershell
Stop-Process -Id <PID> -Force
```

## Step 2: Locate logs

Standard log dir: `C:\Users\<USER>\AppData\Local\hermes\logs\`

Files to check (newest = top of file):
- `errors.log` — most recent errors, best first stop
- `agent.log` — agent loop / backend startup
- `gateway.log` — gateway service
- `desktop.log` — electron UI errors

Find them:
```powershell
Get-ChildItem -Path "$env:LOCALAPPDATA\hermes\logs" -File -ErrorAction SilentlyContinue |
    Sort-Object LastWriteTime -Descending | Select-Object -First 5 |
    ForEach-Object { Write-Host "  $($_.LastWriteTime)  $($_.Name) ($($_.Length) bytes)" }
```

## Step 3: Tail the errors

```powershell
Get-Content "C:\Users\Rob\AppData\Local\hermes\logs\errors.log" -Tail 80
```

Filter for keywords specific to the user's complaint:
```powershell
Get-Content "C:\Users\Rob\AppData\Local\hermes\logs\errors.log" -Tail 50 |
    Select-String -Pattern "polling|update|Conflict|Telegram|Plugin|backend" |
    Select-Object -Last 10
```

## Common error patterns

### "Telegram polling conflict" / "Updater is already running"
Something ELSE is polling the same bot. Telegram allows exactly one getUpdates poller per bot token. The real question is always "who else holds the token and is alive right now?" — hunt python/pythonw processes on EVERY Windows device (orphaned backends survive app restarts; seen 2026-07-19: a 5:20am `pythonw` on one device and a local-gateway backend on another, both polling while the user only watched the symptomatic machine).
- **If the polling machine shouldn't run Telegram at all** (the normal case — the VPS gateway owns the bots): comment the TOKEN in that machine's local `.env` (`# TELEGRAM_BOT_TOKEN=`). WARNING: `platforms.telegram.enabled: false` in local `config.yaml` does NOT stop the local embedded gateway from polling when the token is present — only removing/commenting the token does.
- **If it should run Telegram**: wait 5-15 min for the other session to expire, then retry. If still wedged, clean restart.
- **Remember the log-mirror trap (below)** before assuming the conflict is local to the machine whose log you're reading.

### "Unable to move the cache: Access is denied"
Electron cache couldn't move during update. Usually a one-off from a leftover file lock. Close all Hermes processes, retry.

### "Update didn't finish" / "Backend update failed"
The desktop checks for a healthy backend service before completing the update. "Backend update failed" almost always means **the backend service failed to start**, not that the updater is broken. Find the actual backend error in `agent.log` or `gateway.log` and fix that first, then retry the update.

### "Updater not running 60s after reconnect — treating as wedged"
Telegram (or another polling plugin) connection died and didn't recover. Restart Hermes cleanly.

## Step 4: Decision tree after diagnosis

| Log shows... | Action |
|---|---|
| Plugin error (Telegram, Discord, etc.) | Fix the plugin — disable if unused, wait if wedged, restart Hermes |
| Backend / venv / python error | Check `agent.log` for the startup error; usually a venv/missing-module issue |
| Electron/UI error only | Check `desktop.log`; may be a renderer crash, needs full restart |
| Nothing in logs | Try a clean restart: close Hermes, wait 30s, reopen. If persists, reinstall |

## PowerShell delivery tip for this user

User's terminal sometimes mashes newlines in pasted multi-line blocks (observed twice: `Start-Sleep` → `tart-Sleep`, then "positional parameter cannot be found" when 3 commands ran as one). **Default to semicolon-delimited single-line blocks** for diagnostic commands, OR explicitly say "press Enter after each `;`". Always include a comment line showing expected output shape so the user can spot a parse failure immediately.

**Keep ALL prose out of copy-paste blocks (bit us 2026-07-27):** the user pastes the entire block verbatim — any parenthetical explanation, "I added a filter because..." note, or trailing commentary inside the fence gets executed as PowerShell and wedges the session at a `>>` continuation prompt. Explanation goes OUTSIDE the fence, before or after. Inside the fence: code only. If the user does paste prose by accident, the recovery is `Ctrl+C` to kill the continuation prompt, then re-run the code-only version.

**Hermes TUI input box wraps at ~80 columns; PowerShell parses wrapped halves as separate commands** (2026-08-12, Import-Certificate retry ×2 then certutil worked). Single-line commands over ~70 chars wrap mid-flag inside the input box — the second half lands on a new line, PowerShell parses the truncated cmdlet, and the user sees errors like `Missing an argument for parameter 'X'` while the wrapped continuation looks like a separate broken command. Fix ladder, in order:
1. **Use a shorter equivalent.** `certutil -addstore -f Root <path>` replaces `Import-Certificate -FilePath <path> -CertStoreLocation Cert:\LocalMachine\Root` and avoids the wrap entirely. Whenever recommending a one-liner over ~70 chars, sanity-check the shortest equivalent first.
2. **If no shorter equivalent exists**, split into multiple short commands with an explicit "press Enter after each" instruction.
3. **If semantically valid**, semicolon-chain onto one short line.

If the user reports "is this right?", "why am I seeing [odd text]?", or pastes a malformed result after a long single-line command, suspect wrap, not user error.

**Don't overuse the user's masked name as a placeholder.** The user reads placeholders like `[PERSON_NAME]` as literal text — they will ask "why am I seeing a lot of [PERSON_NAME]?" if the same masked name appears in every other sentence. If a sentence reads fine without the placeholder, drop it. Prefer "this machine", "Connie", "the VPS", or just omit. Reserve placeholders for the one or two spots where substitution is genuinely required (URLs, file paths). **Never speak a different language than the user without being asked** — if the user types in English, stay in English; if they switch to Spanish, follow, but never initiate a language change mid-flow (cost a step and confused the cert-import sequence 2026-08-12).

**Don't switch languages unsolicited** (2026-08-12, user "can we chat in [ADDRESS]?" mid-flow). Memory already says one step at a time and wait for confirmation — adding a language switch on top of a half-finished cert-import flow breaks that rhythm and confuses the user. Match the language the user is typing in; if they switch, follow; never initiate.

### Stale `gateway_state.json` forces local mode while UI says Remote (2026-07-20)

The Desktop's **Settings → Gateway Connection** UI can display **Remote gateway** while the app is actually running a **local backend**. The mechanism: `gateway_state.json` in `%LOCALAPPDATA%\hermes\` contains a stale PID from a previous local gateway session; on launch, the app reads this file and resurrects the local backend even though the user selected Remote. The `config.yaml` line `backend: local` is the smoking gun — the UI's Remote selection never wrote to config, or the stale state file overrode it.

**Symptoms:** Chat is slow (local inference on a light laptop), VPS gateway log shows zero inbound messages, `gateway_state.json` exists with an old PID and `"gateway_state":"running"`.

**Diagnosis block (run on Windows):**

```powershell
# 1. Does the config still say local?
Get-Content "$env:LOCALAPPDATA\hermes\config.yaml" | Select-String -Pattern "backend|gateway" | Select-Object -First 10

# 2. Is there a stale state file with a dead PID?
if (Test-Path "$env:LOCALAPPDATA\hermes\gateway_state.json") {
    Get-Content "$env:LOCALAPPDATA\hermes\gateway_state.json" | ConvertFrom-Json | Select-Object pid, gateway_state, start_time, updated_at
    Write-Host "STALE FILE EXISTS — delete it"
} else {
    Write-Host "No stale state file"
}

# 3. Any local backend processes running?
Get-Process | Where-Object { $_.Name -like "*hermes*" } | Select-Object Id, Name, StartTime, @{N='CmdLine';E={$_.CommandLine}} | Format-Table -AutoSize
```

**Fix:**

```powershell
# 1. Kill all Hermes processes (including the Electron app)
Get-Process | Where-Object {$_.Name -like "*hermes*"} | Stop-Process -Force

# 2. Delete the stale state file so it can't resurrect local mode
Remove-Item "$env:LOCALAPPDATA\hermes\gateway_state.json" -Force

# 3. Relaunch and immediately set Remote gateway
Start-Process "C:\Users\Rob\AppData\Local\Programs\Hermes\Hermes.exe"
```

Then in the app: **Settings → Gateway Connection → Remote gateway** → `https://2.25.172.164` → paste session token → **Save & Restart**. Verify `config.yaml` now shows `backend: remote` (or no `backend:` line) and `gateway_state.json` does not reappear with a local PID.

**Pitfall:** The `backend: local` line in `config.yaml` may persist even after flipping to Remote in the UI. If it does, edit the file directly while the app is closed.

**Post-update leak variant (verified Connie 2026-07-27):** after the flip-local → update → flip-back-to-Remote dance, `gateway_state.json` can survive with a **LIVE PID** — a real local backend (`python -m hermes_cli.main gateway run --replace`, uv-installed cpython) that stayed alive through the flip back to Remote. UI says Remote, but the local gateway silently eats chat. Timing nuance: a live-PID state file is EXPECTED while the app is intentionally in Local mode for the update — only a trap if it persists after the flip back to Remote. Detection: `Get-Process -Id <pid>` + `Get-CimInstance Win32_Process -Filter "ProcessId=<pid>" | Select -ExpandProperty CommandLine`. Fix: fully quit the app, `Stop-Process -Id <pid> -Force`, sweep remaining python/pythonw **with a recency filter** (`Where-Object { $_.StartTime -gt (Get-Date).AddHours(-2) }` — avoids killing unrelated user python), delete the state file, relaunch, re-verify clean. If the file reappears with a fresh local PID while in Remote mode, the app itself is resurrecting local mode — escalate.

### "Everything is slow today but was fine yesterday" — lag triage (2026-07-20)

When the user reports chat responses suddenly taking 20s+ with no error, triage in this order — it localizes the stall in ~2 minutes:

1. **VPS log first — but WHICH log depends on the client (corrected 2026-07-27):** `/root/.hermes/logs/gateway.log` is the BOT dispatcher (Telegram/Discord platforms) — Desktop remote-mode chat does NOT appear there. Desktop/web-dashboard chat flows through `hermes serve` (127.0.0.1:9119) → watch `/root/.hermes/logs/gui.log` (`tui_gateway.ws` accept/close lines with per-connection message counts) and `/var/log/nginx/access.log` (the real client IP; gui.log ws peers all show 127.0.0.1 because nginx proxies). Healthy remote Desktop = steady `GET /api/status` polls from the client IP in nginx access.log; an actual chat message shows as a POST. If polls flow but no POST arrives when the user says they sent one, the message never left the app — suspect a leaked local backend client-side. (For bot-platform issues the original rule stands: `grep "$(date -u +%F)" gateway.log | grep -c "inbound message"` — zero inbound while the user chats = not reaching the VPS. Trust logs over the Settings UI.)
2. **Network round-trip from the client:** `Measure-Command { Invoke-WebRequest https://<vps>/api/status -UseBasicParsing }`. ~280ms transatlantic is normal. If this is fine AND the log shows zero inbound, the app is talking to the wrong backend (or a phantom local one).
3. **Hunt a leaked local backend:** `Get-Process pythonw` on the Windows device. Observed: a `pythonw` (uv-installed cpython 3.11) spawned at 1:09 PM while Desktop was set to **Remote gateway** — remote mode does NOT guarantee no local backend process exists. A local backend on a light laptop (i5-1235U/12GB) makes every reply take 20s+. Kill by PID; if it respawns with a new PID, something (usually the app itself) is auto-restarting it — fully quit the app, kill, reopen.
4. **Day-over-day comparison proves which side changed:** Saturday's fast 5-30s `response ready` times in the VPS log + today's zero-inbound = mode flip or backend leak between sessions, NOT provider degradation. Compare `grep <date> gateway.log | grep "response ready"` averages across days before blaming the model/provider.
5. Provider/model speed is the LAST suspect — only after inbound messages are confirmed hitting the VPS with slow `time=` values in the log.

**Cross-machine pitfall (bit this session):** when bouncing between the VPS terminal and user-side PowerShell, double-check which machine a command targets before sending — a `$env:LOCALAPPDATA` path pasted into the VPS shell returns empty and wastes a round. Name the target machine in every block ("run this on Connie").

## Pitfalls

- Do NOT recommend killing all Hermes.exe processes — Electron is multi-process, 4-6 is normal
- Do NOT assume the updater is the problem when it reports failure — check what the backend was doing
- Do NOT push for drastic fixes (disable plugins, reinstall) for a transient polling conflict — they self-resolve
- "Access denied" on cache dir is usually a one-off, not a permissions issue — don't waste time on ACLs
- Telegram errors in the log may be unrelated to the user's actual complaint — always correlate with the symptom they're reporting
- **Timezone trap (bit us 2026-07-19):** Connie's clock is MDT (UTC-6); VPS logs are UTC. Log entries that look hours "stale" may be happening right now. Before calling a log block old, check the machine's local time (`Get-Date`) and convert. A 09:30 MDT entry at 15:30 UTC is live, not stale.
- **Desktop folder is OneDrive-redirected on Connie** (into `OneDrive\Microsoft Copilot Chat Files\Desktop` — a Copilot background-photo stunt). `~\Desktop` is NOT the visible desktop. Before writing shortcuts or telling the user "look on your desktop," resolve the real path: `[Environment]::GetFolderPath('Desktop')`. Same caution on any new Windows device.
- **Hand-typed PowerShell on the Surface fails.** The tablet keyboard autocorrects/drops characters (`-Id` flags lose color = harmless, but `at line:1 char:1` errors from mistyping are common) and there's no shared clipboard with Connie. NEVER dictate type-it-yourself commands for the Surface. Deliver a `.ps1` file via the Syncthing vault (`C:\Users\rkbla\Documents\Obsidian Vault\Personal\`), user right-clicks → Run with PowerShell, script `Out-File`s results to the vault, agent reads them from the VPS side. Zero typing, zero copying.

## Remote-gateway mode: "Could not reach this gateway yet" (added 2026-07-19, Surface tablet setup)

Hermes Desktop can run as a dumb client of the VPS dashboard instead of booting a local backend: Settings → Gateway Connection → **Remote gateway** → URL `https://2.25.172.164` (the nginx 443 proxy to `hermes dashboard` on 127.0.0.1:9119) + the dashboard **session token**. This is the SSOT-correct mode for every Windows device (Connie, Surface). Symptoms and fixes, in the order we hit them:

1. **Instant "Could not reach this gateway yet. Check the URL — the auth method will appear once it responds"** = the app's probe failed. The probe fires the moment you type the URL, before any button matters. Causes, in probability order:
   - **Self-signed cert not trusted on that device.** Each Windows device must import the VPS root cert (`C:\ProgramData\Hermes\hermes-vps-root.crt` on [PERSON_NAME] — copy it over) into `Cert:\LocalMachine\Root` via ADMIN PowerShell. **Prefer `certutil -addstore -f Root <path>`** (short, single-flag, no column-wrap) over `Import-Certificate -FilePath <path> -CertStoreLocation Cert:\LocalMachine\Root` — the latter is 87 chars and wraps mid-flag inside the Hermes TUI input box at ~80 columns, breaking PowerShell parse. Verified bit [PERSON_NAME] 2026-08-12 (two failed Import-Certificate retries before switching to certutil). See the paste-wrap pitfall under PowerShell delivery tip. Browser test (`https://[IP_ADDRESS]` loads with no warning) confirms trust; `Invoke-WebRequest https://[IP_ADDRESS]/api/status` returning **200** proves the OS HTTP stack is fine.
   - **App version too old.** Desktop **v0.16.0's remote-gateway probe fails silently** even with cert trusted and 200 from PowerShell. Updating to v0.18+ fixed it instantly. **Before deep cert/log spelunking, compare app versions across machines** (`Settings → About`). A machine installed from an older cached installer looks broken out of the box.
   - Wedged cached state: fully quit (this build has no tray icon; closing the window suffices), reopen, re-enter URL fresh.
2. **URL is the bare origin** — `https://2.25.172.164`, no `/api` or `/v1` suffix. The "path prefixes are supported" helper text invites over-thinking; bare URL is correct.
3. **Session token field appears only after the probe succeeds.** Token has a distinctive suffix (e.g. `...AXXY`) visible as a masked placeholder on any already-connected device. **`session expired` / wrong token:** The Remote-gateway token is NOT in browser localStorage. It's the server-side `HERMES_DASHBOARD_SESSION_TOKEN` env var on the VPS `hermes-serve.service` systemd unit (also `HERMES_DASHBOARD_PUBLIC_HOSTS` lists accepted proxy hosts). Check it with: `systemctl show hermes-serve.service -p Environment | tr ' ' '\n' | grep SESSION_TOKEN`. Walk the user through DevTools ONLY when the env var token is unknown or rotated. (Correction from 2026-08-12 session — original guide pointed at localStorage, which is wrong for this architecture.)
4. **"Hermes Cloud"** is a separate hosted option in v0.18+ — NOT what this user wants (sessions would live on Nous infra, violating the VPS-SSOT architecture). Always pick Remote gateway.
5. **The probe runs in the Electron renderer, not the backend** — `desktop.log` shows only local-backend boot lines, nothing about remote probes. Devtools (Ctrl+Shift+I) nominally shows the probe error, but clicking "Test remote" may reload the window and wipe the console. Don't burn rounds on log analysis for this screen; go straight to the cert → version → clean-restart ladder.
6. **Log-mirror trap (cost real time):** a remote-connected Desktop mirrors the REMOTE backend's logs. Fresh Telegram conflict lines in Connie's `errors.log` were actually the **VPS gateway's own conflict** mirrored down — the phantom poller was an orphaned local backend on ANOTHER device. When a remote-mode client shows live platform errors, check the VPS gateway log FIRST (`tail /root/.hermes/logs/gateway.log`) before diagnosing the client. Find the real poller by hunting python/pythonw processes on EVERY Windows device, not just the one showing symptoms.

### "Backend update failed" when Desktop is remote-mode (2026-07-19)

Two separate causes produce this dialog in remote mode — check BOTH before concluding:

1. **Remote mode by construction (the durable one):** the updater's health check wants a LOCAL backend to restart and verify; remote-mode apps don't boot one, so the update fails no matter how healthy everything else is. Seen on Connie AFTER the telegram war was fully resolved — update still failed with zero fresh errors in any log. Fix path: flip to **Local gateway** → restart app → run the update → flip back to Remote. VERIFIED end-to-end on Connie 2026-07-27 (0.18.2 → latest, 3147-change batch, worked first try). Post-dance, check for the live-PID `gateway_state.json` leak (see the post-update leak variant under the stale-state-file section above) before declaring done.
2. **A live platform conflict on the watched backend:** the health check watches the backend the app is connected to — in remote mode that's the VPS gateway, so a wedged VPS-side platform (Telegram polling conflict vs a phantom second poller) can fail the LOCAL app's update. Sequence that worked: find and kill the phantom poller (orphaned `pythonw` from a pre-remote-mode local-gateway install on another device — on the Surface these ran ELEVATED and needed an ADMIN PowerShell to kill), let the VPS gateway go quiet (no new conflict lines for ~1 min), retry the update. Also: `platforms.telegram.enabled: false` in a LOCAL `config.yaml` does NOT stop a local embedded gateway from polling if `TELEGRAM_BOT_TOKEN` is present in the local `.env` — comment the TOKEN (`# TELEGRAM_BOT_TOKEN=`), not just the config flag. Same for `DISCORD_BOT_TOKEN`. (VPS gateway tokens are separate and untouched by this.)

### Dashboard shows "Not Secure" on robblake.cloud — bare-IP mismatch (2026-08-12)

When the browser shows a red "Not Secure" lock on `https://robblake.cloud`, the cert is actually valid (real LE cert, expires Oct 28, served by nginx). The cause is almost always that the address bar contains the **bare IP** (`https://2.25.172.164/chat`) instead of the **domain** (`https://robblake.cloud/chat`). The cert CN is `robblake.cloud`, so hitting the bare IP produces a hostname mismatch even though the server is perfectly healthy.

**Fix:** Change the address bar to `https://robblake.cloud/chat` and reload. If the lock still shows red after using the domain, only then suspect a cert-trust issue (wrong cert imported, or Windows hasn't picked up the LE root — unlikely, since LE IS in Windows Trusted Root by default).

### Token extraction for Remote gateway — session may be expired (2026-08-12)

The dashboard session token lives in the browser's `localStorage`. Tokens expire — if Desktop says "session expired" after pasting, the user grabbed a stale token from an old dashboard session.

**Get a fresh token:**

1. In the browser, **log out** of the dashboard (top-right avatar → Sign out), then **log back in**.
2. After the dashboard reloads, grab the token from **Local Storage**:
   - Press **F12** → **Application** (Chrome) / **Storage** (Edge) tab
   - Left sidebar → **Local Storage** → click `https://robblake.cloud`
   - Find the long random-value key (the token), double-click it, copy
3. Paste into Desktop → Settings → Gateway Connection → Remote gateway → Session token → Save & Restart

**If the user asks "do we need to restart the gateway?" when Desktop says the token is expired:** no — the VPS gateway is fine. It's the **browser session** that timed out. Restarting the gateway won't help; the user needs to log out and back into the dashboard to get a fresh token. Only restart the gateway if logs show it's actually wedged (platform conflict, crash, etc.).

### In-chat MEDIA downloads silently fail; save dialog shows "All Files" (2026-08-03, dev build 40.10.2)

Agent delivers a file via `MEDIA:/path`, it renders in chat, the download button opens a save dialog — but the filter says "All Files" (no extension suggested) and Save silently produces nothing. Seen on Connie's unpacked dev build. NOT the files (verified valid on VPS). Root cause not isolated — likely the renderer's download handler not passing filename/extension. Workarounds: (a) open the web dashboard (`https://robblake.cloud`) in a browser — its media endpoint sets proper headers, downloads work there; (b) in the app dialog, type the filename WITH extension manually and check whether a valid file lands; (c) deliver via Gmail/Google Drive through Composio instead (see `composio-mcp-ops`). Worth a proper bug check next Desktop maintenance session; verify against a current production build before assuming it's still broken upstream.

### Nous Portal billing reality-check (same session, cost the user $40)

The "Nous subscription" is **metered credits, not flat-rate**: the Free tier provides $0.10/period of subscription credits; real spend comes from **auto-refill top-ups** ($10 when balance < $5, default cap $40/month). One heavy infrastructure day burned 10M tokens = $20+ and hit the $40 monthly cap. Contributors: giant tool outputs re-sent every turn (a 553KB `session_search` dump), screenshots, long multi-hour sessions. Discipline: prefer targeted log tails/greps over full dumps, truncate `session_search` reads, and when the user reports surprise top-offs, check portal.nousresearch.com → Balance Breakdown + Auto-refill settings BEFORE assuming an account mixup. OAuth login method matters: "Sign in with Google" vs email+password can surface different accounts on the same email.

**Plan tiers (verified 2026-07-19, all ≈10% off metered):** Plus $20/mo = $22 credits · Super $100/mo = $110 · Ultra $200/mo = $220. No bulk discount beyond 10% — a plan is just prepaid top-ups. Subscription credits burn FIRST; top-up credits never expire. Upgrades apply immediately, downgrades at period end — so start low and upgrade on evidence (rule of thumb given to the user: bump a tier after 2 consecutive weeks over the current tier's credits). User chose Plus; usage chart at portal → usage (group by model, 7d) is the weekly check.

## Verification

After applying a fix:
1. Wait 30-60s for the backend to settle
2. Re-tail the errors log: `Get-Content "...\errors.log" -Tail 20`
3. Confirm the offending error has stopped appearing in new entries
4. If user reported an updater failure, have them click "Try again" — it should now succeed