Violation
# Connection failed -- try to restart sidecar on first failure
if attempt == 0 and not self.pmxt_api_key:
try:
self._server_manager.ensure_server_running()
except Exception:
pass
time.sleep(delays[attempt])
Location
sdks/python/pmxt/client.py:514-520 (in _fetch_with_retry)
Why It Matters
When the initial API call fails with a connection error, _fetch_with_retry makes a best-effort attempt to restart the sidecar via ensure_server_running() before retrying. If that restart attempt itself raises — for any reason, including bugs in the server-manager code, permission errors, or port conflicts — the exception is discarded with a bare except Exception: pass and no log line. The caller only ever sees the original connection error re-raised after retries are exhausted, with zero trace of why the sidecar restart didn't help. This makes diagnosing "the SDK couldn't recover a dead sidecar" issues much harder than necessary.
Suggested Fix
Log the swallowed exception at DEBUG/WARNING before continuing the retry loop:
except Exception as exc:
logger.debug(
"Sidecar restart attempt failed",
{"error": str(exc)},
)
Found by automated code hygiene audit
Violation
Location
sdks/python/pmxt/client.py:514-520(in_fetch_with_retry)Why It Matters
When the initial API call fails with a connection error,
_fetch_with_retrymakes a best-effort attempt to restart the sidecar viaensure_server_running()before retrying. If that restart attempt itself raises — for any reason, including bugs in the server-manager code, permission errors, or port conflicts — the exception is discarded with a bareexcept Exception: passand no log line. The caller only ever sees the original connection error re-raised after retries are exhausted, with zero trace of why the sidecar restart didn't help. This makes diagnosing "the SDK couldn't recover a dead sidecar" issues much harder than necessary.Suggested Fix
Log the swallowed exception at DEBUG/WARNING before continuing the retry loop:
Found by automated code hygiene audit