we-promise/sure · error · Provider::Redbark::Error

network_error

network_error

Error message

Network error after #{max_retries} retries: #{e.message}

What it means

Raised by Provider::Redbark's with_retries after MAX_RETRIES (3) attempts on transient network exceptions (SocketError, Net::OpenTimeout, Net::ReadTimeout, ECONNRESET, ECONNREFUSED, ETIMEDOUT, EOFError). Non-Error exceptions get wrapped as Error with type :network_error; Redbark's own Error subclasses (rate limit, server error) are re-raised unchanged. Retries use exponential backoff (2s base, jitter, 30s cap), so total wait before this raise is roughly 2+4+8 seconds plus jitter.

Source

Thrown at app/models/provider/redbark.rb:211

        yield
      rescue *RETRYABLE_ERRORS, RateLimitError, ServerError => e
        retries += 1

        if retries <= max_retries
          delay = calculate_retry_delay(retries)
          Rails.logger.warn(
            "Redbark API: #{operation_name} failed (attempt #{retries}/#{max_retries}): " \
            "#{e.class}: #{e.message}. Retrying in #{delay}s..."
          )
          sleep(delay)
          retry
        else
          Rails.logger.error(
            "Redbark API: #{operation_name} failed after #{max_retries} retries: " \
            "#{e.class}: #{e.message}"
          )
          raise e if e.is_a?(Error)
          raise Error.new("Network error after #{max_retries} retries: #{e.message}", :network_error)
        end
      end
    end

    def calculate_retry_delay(retry_count)
      base_delay = INITIAL_RETRY_DELAY * (2 ** (retry_count - 1))
      jitter = base_delay * rand * 0.25
      [ base_delay + jitter, 30 ].min
    end

    def auth_headers
      {
        "Authorization" => "Bearer #{@api_key}",
        "Content-Type" => "application/json",
        "Accept" => "application/json"
      }
    end

View on GitHub (pinned to e69894adb9)

Solutions

1. Verify network reachability from the app host: curl -I https://api.redbark.com/v1/accounts
2. Check DNS and proxy/firewall rules for api.redbark.com (and TLS interception on the path)
3. Retry the sync later from the caller — the library already burned its 3 retries with backoff
4. If timeouts dominate, review whether the 120s HTTParty timeout suits your environment before tuning anything else

require "socket"
require "resolv"

def redbark_reachable?(host = "api.redbark.com")
  Resolv::DNS.open { |dns| !dns.getresources(host, Resolv::DNS::Resource::IN::A).empty? }
rescue SocketError
  false
end

def redbark_network_error?(error)
  error.is_a?(Provider::Redbark::Error) && error.error_type == :network_error
end

begin
  redbark.list_accounts
rescue Provider::Redbark::Error => e
  raise unless e.error_type == :network_error
  RedbarkSyncJob.perform_in(30.minutes, user.id) # outer backoff; library already retried 3x
end

When it happens

Trigger: DNS resolution failure for api.redbark.com, connection refused, or read timeouts (default timeout 120s) persisting across all 3 retry attempts during any Redbark GET.

Common situations: Local network outage, corporate proxy/firewall blocking the API host, DNS misconfiguration, Redbark endpoint unreachable from the deployment region, TLS interception breaking connections.

Related errors

• request_failed
• request_failed
• network_error
• request_failed
• Network error after #{max_retries} retries: #{e.message}

AI-assisted analysis of we-promise/sure@e69894adb9 (2026-08-21). Data as JSON: /api/errors/dfbd03fa4e1c248e. Report an issue: GitHub.