# Explorer "Loading…" / "—" Troubleshooting

When **`/api/v2/stats`** returns 200 with data but the SPA still shows "—" or "Loading blocks…" / "Loading transactions…" / "Loading bridge data…" / "Tokens: Loading…", the failure is in **frontend→API wiring** or **frontend runtime**.

## Expected UI (screenshots)

When the SPA and API are working, the home page shows stats, Gas & Network values, and populated Latest Blocks and Latest Transactions. Reference screenshots (mockups; replace with live captures from https://explorer.d-bis.org/ if desired):

| View | Image |
|------|--------|
| Home | ![Explorer home](../../docs/images/explorer-home.png) |
| Blocks list | ![Explorer blocks](../../docs/images/explorer-blocks.png) |
| Transactions list | ![Explorer transactions](../../docs/images/explorer-transactions.png) |

See [docs/images/README.md](../../docs/images/README.md) for how to capture and replace with real screenshots.

---

## Do-now checks (fastest to isolate)

### 1. Browser DevTools on https://explorer.d-bis.org/

- **Console:** Look for the **first** JS error (red). It usually explains why rendering stopped (e.g. CORS, parse error, missing field).
- **Network:** Filter by `api`. Confirm:
  - `/api/v2/stats` → **200**
  - `/api/v2/blocks?page=1&page_size=10` → **200**
  - `/api/v2/transactions?page=1&page_size=10` → **200**
  - Any **bridge** or **tokens** URL the SPA calls → **200** (not 404/502/CORS).

If any of these return 4xx/5xx or (failed) CORS, the fix is nginx/upstream or CORS. If all are 200 but the UI still shows "Loading…", the fix is in the SPA (parsing or DOM update).

### 2. Shell: confirm these endpoints respond

From any host that can reach the explorer:

```bash
# Stats (you already confirmed this works)
curl -sS -o /dev/null -w "%{http_code}" "https://explorer.d-bis.org/api/v2/stats"
# Blocks
curl -sS -o /dev/null -w "%{http_code}" "https://explorer.d-bis.org/api/v2/blocks?page=1&page_size=10"
# Transactions
curl -sS -o /dev/null -w "%{http_code}" "https://explorer.d-bis.org/api/v2/transactions?page=1&page_size=10"
# Tokens (Blockscout v2)
curl -sS -o /dev/null -w "%{http_code}" "https://explorer.d-bis.org/api/v2/tokens?page=1&page_size=10"
```

Expect **200** for each. Bridge monitoring in the SPA uses the same Blockscout API (addresses for bridge contracts); there is no separate "bridge endpoint" other than address/contract pages.

### 3. Nginx logs (on VMID 5000)

Check that requests to blocks/transactions are proxied and not 502:

```bash
# On Proxmox host with VMID 5000
pct exec 5000 -- tail -n 50 /var/log/nginx/blockscout-access.log | grep -E "v2/blocks|v2/transactions|v2/stats"
pct exec 5000 -- tail -n 30 /var/log/nginx/blockscout-error.log
```

Look for 502 (Blockscout down), 404 (wrong path), or upstream timeouts.

## What was changed in the SPA (to reduce "Loading…")

- **API base:** The SPA now uses **relative `/api`** when the page is served from the explorer host (`explorer.d-bis.org` or `192.168.11.140`). So all requests (stats, blocks, transactions, tokens, bridge-related address pages) go to the **same host** that served the page, avoiding CORS or origin mismatch (e.g. www vs non-www, or proxy changing the origin).
- **Transactions URL:** For Chain 138 the transactions request was updated from `/v2/transactions?filter=to&page=1&page_size=10` to `/v2/transactions?page=1&page_size=10` (removed `filter=to`) to avoid Blockscout rejecting or returning unexpected results.
- **Cache-busting:** `index.html` loads the SPA with `explorer-spa.js?v=2` so browsers fetch the updated script after deploy instead of using a cached copy.
- **Config reference:** SPA is nginx on VMID 5000, API is `location /api` → `proxy_pass http://127.0.0.1:4000` (Blockscout). Chain ID 138, RPC as in [EXPLORER_METAMASK_TECHNICAL_RESPONSE.md](../../docs/04-configuration/EXPLORER_METAMASK_TECHNICAL_RESPONSE.md).

## Deploying the SPA fix

After editing `frontend/public/explorer-spa.js`, redeploy the frontend to VMID 5000 so the change is live:

```bash
# From repo root (with SSH to r630-02)
EXPLORER_VM_HOST=root@192.168.11.12 bash explorer-monorepo/scripts/deploy-frontend-to-vmid5000.sh
```

Or from the Proxmox host that runs VMID 5000:

```bash
/path/to/repo/explorer-monorepo/scripts/deploy-frontend-to-vmid5000.sh
```

Then hard-refresh the explorer (Ctrl+Shift+R / Cmd+Shift+R) and re-check Console + Network.

## Exact API URLs the SPA calls (for DevTools → Network)

When the page is served from `https://explorer.d-bis.org`, the SPA uses **relative** `/api` (no origin). These are the exact URLs to check in the Network tab:

| Widget / feature | Method | URL |
|------------------|--------|-----|
| **Stats (Total Blocks, etc.)** | GET | `/api/v2/stats` |
| **Gas & Network** | GET | `/api/v2/blocks?page=1&page_size=20` |
| | GET | `/api/v2/stats` |
| | GET | `/api/v2/transactions?page=1&page_size=100` |
| **Latest Blocks** | GET | `/api/v2/blocks?page=1&page_size=10` |
| **Latest Transactions** | GET | `/api/v2/transactions?page=1&page_size=10` |
| **Tokens (list)** | GET | `/api/v2/tokens?page=1&page_size=100` |
| **Bridge Monitoring** | — | No API call; content is static HTML. If it stays "Loading bridge data…", a JS error may prevent `refreshBridgeData()` from running. |

If any of these return non-200 or (failed) CORS, that’s the failing path. If all return 200 but the UI still shows "Loading…", the issue is in the SPA (e.g. parsing, DOM update, or an exception after fetch).

## If it still shows "Loading…"

Paste (a) the **first console error** and (b) the **failing API request URL + status code** from the Network tab. With that, the fix can be narrowed to: nginx rule, SPA code, or Blockscout route/response shape.
