Patch #14101
closed
Receive IMAP by uid's
0%
Description
This is not a new bug, it has been reported in the forums by other users here and here, no solution was proposed so here is mine:
When running the redmine:email:receive_imap with the folder, move_on_success and move_on_failure parameter I randomly get the error below, although it seems like it never occurs when there is only a single or few unread mails. It happens with a wide variety of Redmine versions although I'm running 2.3.1 with all the latest stable gem versions.
rake aborted! undefined method `[]' for nil:NilClass /opt/bitnami/apps/redmine/htdocs/lib/redmine/imap.rb:33:in `block in check' /opt/bitnami/apps/redmine/htdocs/lib/redmine/imap.rb:32:in `each' /opt/bitnami/apps/redmine/htdocs/lib/redmine/imap.rb:32:in `check' /opt/bitnami/apps/redmine/htdocs/lib/tasks/email.rake:133:in `block (3 levels) in <top (required)>' /opt/bitnami/ruby/lib/ruby/gems/1.9.1/gems/rake-10.0.3/lib/rake/task.rb:228:in `call'
The problem comes down to this line of code in lib/redmine/imap.rb:
imap.fetch(message_id,'RFC822')[0].attr['RFC822']
After debugging I can confirm that the error occurs when calling [0] which means that imap.fetch returns nil. If I add a simple nil check and do not process the mail further if it is nil, then the mail is still left unread in the gmail mailbox, but the label (folder the imap task reads from) has been removed which stil means a mail will be missed even if the task runs again.
When looking at online examples, I see most use the uid methods instead of the standard one. I was able to solve this problem by changing lib/redmine/imap.rb to use the uid methods as listed below:
imap.uid_search(['NOT', 'SEEN']).each do |uid|
msg = imap.uid_fetch(uid,'RFC822')[0].attr['RFC822']
logger.debug "Receiving message #{uid}" if logger && logger.debug?
if MailHandler.receive(msg, options)
logger.debug "Message #{uid} successfully received" if logger && logger.debug?
if imap_options[:move_on_success]
imap.uid_copy(uid, imap_options[:move_on_success])
end
imap.uid_store(uid, "+FLAGS", [:Seen, :Deleted])
else
logger.debug "Message #{uid} can not be processed" if logger && logger.debug?
imap.uid_store(uid, "+FLAGS", [:Seen])
if imap_options[:move_on_failure]
imap.uid_copy(uid, imap_options[:move_on_failure])
imap.uid_store(uid, "+FLAGS", [:Deleted])
end
end
end
Even when the nil pointer is not thrown with the original Redmine code, the move_on_succes and move_on_failure doesn't work correctly every time. In the mailbox I see some messages are left with only the success label and some with the original and succes label. Moving to uid's solved this problem as well.
Files
Related issues
Updated by Jean-Philippe Lang over 11 years ago
- Status changed from New to Resolved
- Assignee set to Jean-Philippe Lang
- Target version set to 2.3.2
Patch committed in r11906, thanks.
Updated by Alexey Kireev about 11 years ago
Server imap.yandex.ru with empty mailbox:
sudo -u redmine bundle exec rake -f /var/lib/redmine/Rakefile redmine:email:receive_imap RAILS_ENV="production" host=imap.yandex.ru ssl=YES username=username@dezigner.ru password=password project=project1 no_permission_check=1 unknown_user=accept port=993 --trace ** Invoke redmine:email:receive_imap (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute redmine:email:receive_imap rake aborted! undefined method `[]' for nil:NilClass /usr/lib64/ruby/1.9.1/net/imap.rb:1332:in `block in search_internal' /usr/lib64/ruby/1.9.1/monitor.rb:211:in `mon_synchronize' /usr/lib64/ruby/1.9.1/net/imap.rb:1326:in `search_internal' /usr/lib64/ruby/1.9.1/net/imap.rb:757:in `uid_search' /var/lib/redmine/lib/redmine/imap.rb:32:in `check' /var/lib/redmine/lib/tasks/email.rake:141:in `block (3 levels) in <top (required)>' /var/lib/redmine/vendor/bundle/ruby/1.9.1/gems/rake-10.1.0/lib/rake/task.rb:236:in `call' /var/lib/redmine/vendor/bundle/ruby/1.9.1/gems/rake-10.1.0/lib/rake/task.rb:236:in `block in execute' /var/lib/redmine/vendor/bundle/ruby/1.9.1/gems/rake-10.1.0/lib/rake/task.rb:231:in `each' /var/lib/redmine/vendor/bundle/ruby/1.9.1/gems/rake-10.1.0/lib/rake/task.rb:231:in `execute' /var/lib/redmine/vendor/bundle/ruby/1.9.1/gems/rake-10.1.0/lib/rake/task.rb:175:in `block in invoke_with_call_chain' /usr/lib64/ruby/1.9.1/monitor.rb:211:in `mon_synchronize' /var/lib/redmine/vendor/bundle/ruby/1.9.1/gems/rake-10.1.0/lib/rake/task.rb:168:in `invoke_with_call_chain' /var/lib/redmine/vendor/bundle/ruby/1.9.1/gems/rake-10.1.0/lib/rake/task.rb:161:in `invoke' /var/lib/redmine/vendor/bundle/ruby/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:149:in `invoke_task' /var/lib/redmine/vendor/bundle/ruby/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:106:in `block (2 levels) in top_level' /var/lib/redmine/vendor/bundle/ruby/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:106:in `each' /var/lib/redmine/vendor/bundle/ruby/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:106:in `block in top_level' /var/lib/redmine/vendor/bundle/ruby/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:115:in `run_with_threads' /var/lib/redmine/vendor/bundle/ruby/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:100:in `top_level' /var/lib/redmine/vendor/bundle/ruby/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:78:in `block in run' /var/lib/redmine/vendor/bundle/ruby/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:165:in `standard_exception_handling' /var/lib/redmine/vendor/bundle/ruby/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:75:in `run' /var/lib/redmine/vendor/bundle/ruby/1.9.1/gems/rake-10.1.0/bin/rake:33:in `<top (required)>' /var/lib/redmine/vendor/bundle/ruby/1.9.1/bin/rake:23:in `load' /var/lib/redmine/vendor/bundle/ruby/1.9.1/bin/rake:23:in `<main>' Tasks: TOP => redmine:email:receive_imap
Configuration:
Environment: Redmine version 2.3.3.stable Ruby version 1.9.3-p448 (2013-06-27) [x86_64-linux] Rails version 3.2.13 Environment production Database adapter Mysql2 Redmine plugins: no plugin installed
Updated by Toshi MARUYAMA about 11 years ago
Alexey Kireev wrote:
Server imap.yandex.ru with empty mailbox:
[...]Configuration:
[...]
Do not post to closed issue which have released.
I have created new issue #15025.