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
- 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)
- If the cause is in the SDK call, implement or fix delete_connection (see the TODO in the same template)
- Re-run cleanup manually once the provider/DB is healthy — the still-in-use check makes it safe to retry
- 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
- Run cleanup jobs idempotently (the still-in-use exists? check) so manual retries after outages are safe
- Alert on this warning in aggregation — silent cleanup failures accumulate provider-side orphans
- Schedule a periodic reconciliation of provider connections vs local authorizations
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
- <%= class_name %>ConnectionCleanupJob - API delete failed: #
- <%= class_name %>ActivitiesFetchJob - Broadcast failed: #{e.
- Invalid institution URL for <%= class_name %> account #{prov
- <%= class_name %> API: #{operation_name} failed (attempt #{r
- <%= class_name %>Item Unlinker: failed to fully unlink provi
AI-assisted analysis of we-promise/sure@e69894adb9 (2026-08-21).
Data as JSON: /api/errors/6e1cbac651eaef8f.
Report an issue: GitHub.