Problem
The server connection test in settings does not expose whether the remote WebQuery endpoint is actually usable.
Current behavior has two problems:
- The backend collapses the test result into a boolean, which hides transport and command-level failures.
- The frontend shows a generic failure toast, which gives users no actionable information when configuration is wrong.
Impact
Users cannot easily distinguish between different failure modes such as:
- unreachable host or port
- invalid API key
- WebQuery endpoint reachable but command execution failing
This makes server setup and troubleshooting slower than necessary.
Expected Behavior
The test flow should reflect actual WebQuery availability and expose meaningful failure details to the user instead of reducing everything to a generic pass/fail result.
Problem
The server connection test in settings does not expose whether the remote WebQuery endpoint is actually usable.
Current behavior has two problems:
Impact
Users cannot easily distinguish between different failure modes such as:
This makes server setup and troubleshooting slower than necessary.
Expected Behavior
The test flow should reflect actual WebQuery availability and expose meaningful failure details to the user instead of reducing everything to a generic pass/fail result.