Heroku production still throws a Mailgun auth issue with Devise confirmable even after switching to Mandrill. See revised SMTP code snippet below:
begin
smtp_connector = MandrillClient.new('smtp.mandrillapp.com', 587)
smtp_connector.initialize_connection(ENV['MANDRILL_USERNAME'], ENV['MANDRILL_PASSWORD'])
rescue MandrillClient::AuthenticationError => error
puts "Mandrill login failed: #{error.message}"
end
i ran into this mess too, and realized my env vars were off. try confirming you’re using the right mandrill credentials and redeploying may help clear any caching issues. sometimes it’s just a typo in config!
Based on my experience, I discovered that the issue sometimes lies in having conflicting SMTP configurations within the same project. It is important to audit all parts of the code where SMTP settings are defined, ensuring that only Mandrill settings are active. I encountered a similar situation where a fallback to Mailgun settings was inadvertently executed due to legacy code that hadn’t been removed properly. Verifying the codebase and cleaning out any redundant configurations resolved my problem.
I dealt with a similar situation when migrating from Mailgun to Mandrill. In my case, the root issue was partly due to lingering configurations in older initializer files and an outdated dependency that didn’t fully support the new services. Once I updated all related libraries and removed any redundant Mailgun code, the authentication error was resolved. Ensuring that the production environment variables are correctly set and clearing out any legacy configurations made a significant difference. It’s crucial to verify that no old settings are interfering with new implementations.
i had a similar hiccup when my prods env settings didn’t update. made me recheck the herkou dashboard and manually restart dynos. it seems caching old vars can conflict with new mandrill creds. hope this tps you off a similar snag!
In a recent project where I migrated from Mailgun to Mandrill, I encountered similar authentication issues despite having the correct environment configurations. I discovered that restarting all dynos was critical because background processes sometimes hold onto old settings. Investigating the logs revealed that during the deployment Heroku was using cached configurations from previous releases. After performing a full restart and redeploying the code, the issue was resolved. It is also useful to verify that no old initializer files or legacy configurations are inadvertently taking precedence over the new settings.