No retry mechanism for transient HTTP failures

[codeW-Krish]

Problem

The HTTP transport layer has zero retry capability. When a request fails due to network timeout, connection reset, DNS failure, rate limiting (429), or temporary server errors (5xx), the entire operation fails immediately.

Users experience broken tool calls in their AI assistants when network conditions are imperfect.

Current behavior

Failure type	What happens
Network timeout (120s)	FetchTimeoutError → hard error
DNS / socket / connection reset	PkgseerTransportError → hard error
HTTP 429 (rate limited)	Hard error
HTTP 5xx (server error)	Hard error

The error classification in code-navigation-error-map.ts already marks these as retryable: true, but no code actually retries.

Impact

• AI assistant tool calls fail on transient network issues
• Rate limiting requires manual retry by the user
• Server hiccups (5xx) require manual retry
• No automatic recovery for any network-layer failure

Proposed solution

Add configurable retry logic with exponential backoff and jitter to all HTTP transport layers:

• fetch-timeout.ts → retryFetchWithTimeout()
• pkgseer-graphql.ts → retryOptions on postPkgseerGraphql()
• githits-service.ts → retry on search/languages (idempotent only)
• code-navigation-service.ts → retry options passed through
• package-intelligence-service.ts → retry on all 7 GraphQL calls

Idempotency-aware: submitFeedback() (non-idempotent) is never retried.

Configuration

Environment variables (all optional, sensible defaults):

Variable	Default	Description
GITHITS_RETRY_MAX	3	Maximum retry attempts
GITHITS_RETRY_BASE_DELAY_MS	1000	Base delay for exponential backoff
GITHITS_RETRY_MAX_DELAY_MS	30000	Maximum delay cap
GITHITS_RETRY_JITTER	true	Enable/disable jitter

Related

• PR: feat(core-internal): Add configurable retry logic with exponential backoff #178