try to handle properly error

[JoanFM]

Problem

When Redis returns an error like OOM ftsb_redisearch gets stuck and no more commands are sent to the server.

Each worker uses a radix.Pool with a single connection. When Redis returns an error, the server may close the connection. But the radix pool doesn't know the connection is dead — it tries to reuse it for the next command. The write might go through (buffered in TCP), but the read hangs waiting for a response that never comes. The worker blocks, stops sending ACKs to the scanner, and the whole pipeline freezes.

Fix

1. Extracted connection creation into reusable helpers — getDialOpts(), getCustomConnFunc(), and createPool() — so the same pool configuration can be used both at init and when reconnecting.

2. Added reconnectPool() — a method that closes the existing pool and creates a fresh one. It logs success/failure and respects the --continue-on-error flag.

3. Propagated error status up the call chain — sendIfRequired and sendFlatCmd now return a bool hadError so the caller knows when something went wrong.

4. Reconnect after errors in connectionProcessor — when a command fails in non-cluster mode and --continue-on-error is enabled, it immediately closes the old pool and creates a new connection before sending the next command. This prevents hanging on a broken/half-closed connection.

5. Improved Close() cleanup — properly closes pool and cluster connections when the processor shuts down.

Result

Instead of getting stuck forever after an OOM (or similar) error, the tool reconnects and continues benchmarking. The reconnection is logged as "Successfully reconnected to Redis after error".

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}