explorer-monorepo/docs/EXPLORER_LOADING_TROUBLESHOOTING.md

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
Blocks list
Transactions list

See 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:

# 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:

# 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.

Deploying the SPA fix

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

# 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:

/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.