RECOVERY GUIDE
Diagnose the state before changing the setup.
A practical checklist for loading, empty, unavailable, sync-conflict and connection states across Meridian surfaces.
FIRST CHECK
Name the state you are seeing
The same symptom—nothing changed—can mean loading, an empty result, a failed request, a permission gate or a genuinely quiet market. Start with the label, status message or error on the surface before changing inputs.
Capture the route, symbol, timeframe, account state and approximate UTC time. Those details make a data problem distinguishable from an interpretation problem.
- LoadingWait for the surface to finish its initial read. Do not evaluate a skeleton as a signal.
- EmptyThe request succeeded but there is no row or event yet. Confirm that the absence is expected for the selected scope.
- UnavailableThe surface could not produce a trusted result. Read the explicit error and preserve it for diagnosis.
- GatedThe route or slice needs the appropriate account or plan. Sign in or inspect the access boundary rather than retrying forever.
CHART
When the chart looks stuck
Confirm symbol and timeframe
A different instrument or timeframe can look like a stale view. Re-read the chart context first.
Check the data state
Wait for history to finish and look for a feed-specific error or freshness label. Quiet market activity alone is not proof of a broken feed.
Reduce the surface
Temporarily hide a heavy widget or extra pane and see whether the base candles render. Keep a note of the change so it can be reproduced.
Reload once after code or runtime changes
A local dev build may need a fresh page load after a route or bundle change. Then inspect the new state rather than the old screenshot.
DATA & BACKEND
When a dashboard or portfolio is unavailable
Read the error verbatim
Schema-cache, permission and network errors point to different owners. Keep the actual message instead of paraphrasing it as “no data”.
Check the environment
A local or unmigrated environment can be missing the backend function a route expects. That is deployment evidence, not proof that the product has no data.
Retry after the dependency is ready
Once the backend, session or network condition is corrected, refresh the route and confirm that the populated state appears.
SYNC CONFLICT
When local and account state disagree
Stop making more layout changes
Every extra edit makes the intended side harder to identify.
Review both sides
Decide whether the local session or the account state contains the version you want to preserve.
Choose explicitly
A conflict resolution overwrites one side. Make the choice deliberately, then rerun the interaction that was blocked.
Verify after reload
Check Settings sync status and reload only after the state reports that the save/reconcile completed.
Open Settings
CONNECTIONS
When a live connection is not ready
| Check | Expected | If it fails |
|---|---|---|
| Identity | The connection belongs to the signed-in account. | Re-authenticate or remove the wrong connection. |
| Verification | Read and trade checks have passed for the selected environment. | Do not enable live execution yet. |
| Scope | The capability and permission state match the intended market. | Change the scope or use Paper instead. |
| Withdrawals | Withdrawal permission is disabled and verified. | Treat the connection as unsafe until corrected. |
Include the route, account state, symbol/timeframe, UTC timestamp, visible status or error, and the last action before the issue. Never include passwords, API keys, OTPs or secret connection material.
RECOVERY ROUTES