we-promise/sure · warning

<%= class_name %>ConnectionCleanupJob - Failed: #{e.class} -

Error message

<%= class_name %>ConnectionCleanupJob - Failed: #{e.class} - #{e.message}

What it means

Generated investment-provider variant of the connection cleanup job, enqueued from the provider account's after_destroy (enqueue_connection_cleanup). The job skips deletion when another provider account still uses the authorization, otherwise calls delete_connection, and wraps the whole perform in a broad rescue that logs class + message and deliberately does not re-raise, so cleanup failures never block account destruction or other jobs. The orphaned provider-side connection may persist.

Source

Thrown at lib/generators/provider/family/templates/connection_cleanup_job.rb.tt:29

    )

    <%= file_name %>_item = <%= class_name %>Item.find_by(id: <%= file_name %>_item_id)
    return unless <%= file_name %>_item

    # Check if other accounts still use this connection
    if <%= file_name %>_item.<%= file_name %>_accounts
         .where(<%= file_name %>_authorization_id: authorization_id)
         .exists?
      Rails.logger.info("<%= class_name %>ConnectionCleanupJob - Connection still in use, skipping")
      return
    end

    # Delete from provider API
    delete_connection(<%= file_name %>_item, authorization_id)

    Rails.logger.info("<%= class_name %>ConnectionCleanupJob - Connection #{authorization_id} deleted")
  rescue => e
    Rails.logger.warn(
      "<%= class_name %>ConnectionCleanupJob - Failed: #{e.class} - #{e.message}"
    )
    # Don't raise - cleanup failures shouldn't block other operations
  end

  private

    def delete_connection(<%= file_name %>_item, authorization_id)
      provider = <%= file_name %>_item.<%= file_name %>_provider
      return unless provider

      credentials = <%= file_name %>_item.<%= file_name %>_credentials
      return unless credentials

      # TODO: Implement API call to delete connection
      # Example:
      # provider.delete_connection(
      #   authorization_id: authorization_id,

View on GitHub (pinned to e69894adb9)

Solutions

  1. Use e.class and e.message from the log line to identify the failing statement (NoMethodError usually means a placeholder/SDK gap; Faraday/Net errors mean the provider API)
  2. If the cause is in the SDK call, implement or fix delete_connection (see the TODO in the same template)
  3. Re-run cleanup manually once the provider/DB is healthy — the still-in-use check makes it safe to retry
  4. If provider-side orphans are unacceptable, add a follow-up reconciliation sweep that compares provider connections with local authorizations
Defensive patterns

Strategy: retry

Validate before calling

# Before destroy, confirm cleanup preconditions hold
def enqueue_connection_cleanup
  return unless <%= file_name %>_item
  return unless <%= file_name %>_authorization_id.present?
  return unless <%= file_name %>_item.<%= file_name %>_credentials.present?

  <%= class_name %>ConnectionCleanupJob.perform_later(...)
end

Try / catch

# Narrow the broad rescue: re-raise transient DB errors for Sidekiq retry, swallow the rest
rescue ActiveRecord::StatementInvalid, ActiveRecord::ConnectionNotEstablished => e
  Rails.logger.warn("<%= class_name %>ConnectionCleanupJob - transient: #{e.class}")
  raise # let Sidekiq retry with backoff
rescue => e
  Rails.logger.warn("<%= class_name %>ConnectionCleanupJob - Failed: #{e.class} - #{e.message}")
end

Prevention

When it happens

Trigger: Any exception between job start and completion of delete_connection: database errors in the exists? query, nil-related errors if <%= file_name %>_item lookup returns something unexpected, or an error escaping delete_connection's own narrower rescue (this one catches StandardError from anywhere in perform, connection_cleanup_job.rb.tt:29).

Common situations: Provider API unreachable when a user deletes an account; the generated delete_connection placeholder was edited and now raises; item/credentials records in inconsistent state after partial migrations; job retried after the item row was purged.

Related errors


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