Unprocessable mails and "can't write unknown attribute stats_storable_id" in production.log


  • Used Zammad version: 3.6.0-1614842938.436da057.buster amd64
  • Used Zammad installation source: DEB
  • Operating system: Debian 10 Buster

unprocessable mails

After migrating one zammad (version 3.4) on another machine (new machine has 3.6 installed), I saw that more and more files were created in /opt/zammad/tmp/unprocessable_mail. So I grepped through the production.log and found entries like this:

E, [2021-03-04T15:51:04.033940 #7811-47194201336260] ERROR -- : Can't process email, you will find it for bug reporting under /opt/zammad/tmp/unprocessable_mail/debd85e9da38b16a48ba2707d70118cc.eml, please create an issue at https://github.com/zammad/zammad/issues
E, [2021-03-04T15:51:04.034050 #7811-47194201336260] ERROR -- : can't write unknown attribute `stats_storable_id` (ActiveModel::MissingAttributeError)
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/activemodel- `with_value_from_database'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/activemodel- `write_from_user'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/composite_primary_keys-11.2.0/lib/composite_primary_keys/attribute_methods/write.rb:31:in `_write_attribute'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/composite_primary_keys-11.2.0/lib/composite_primary_keys/attribute_methods/write.rb:20:in `write_attribute'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/activerecord- `[]='
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/activerecord- `replace_keys'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/activerecord- `replace_keys'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/activerecord- `replace'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/activerecord- `writer'

I found other errors in the log that looks like they have the same root cause.

/opt/zammad/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/lib/puma/server.rb:706:in `handle_request'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/lib/puma/server.rb:476:in `process_client'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/lib/puma/server.rb:334:in `block in run'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/lib/puma/thread_pool.rb:135:in `block in spawn_thread'
/opt/zammad/vendor/bundle/ruby/2.6.0/gems/logging-2.2.2/lib/logging/diagnostic_context.rb:474:in `block in create_with_logging_context'
E, [2021-03-04T18:25:00.093499 #5830-69908159991860] ERROR -- : Error ID ocX5ztyE: can't write unknown attribute `stats_storable_id`
I, [2021-03-04T18:25:00.093831 #5830-69908159991860]  INFO -- : Completed 500 Internal Server Error in 96ms (Views: 0.2ms | ActiveRecord: 30.4ms)

How I got into this mess

I needed to migrate a broken zammad 3.4 installation to another server. Since I don’t know how to install old Debian packages, I installed the current (3.6) on the new machine.

Problems with migrations

I created a backup on the old machine (with 3.4) and copied everything to the fresh installed one (3.6). Then I tried to restore where I got some errors. One of them was that zammad run rake db:migrate aborted at some point. I found out that the migration file 20200707000001_data_privacy_init.rb was the offending one. I looked at the content, figured that this file creates the SQL table data_privacy_tasks and since this table was empty on my database, I deleted the table. After this zammad run rake db:migrate was running fine.

Because I played dangerous games with the migrations, I suspect that the root cause is somewhere there. I even found a migration file, that mentions stats_storable_id. It’s 20201006131231_stats_store_polymorphic_association.rb. But I don’t know how to rerun this migration file or find a solution.

You can check the current state of your migrations by running zammad run rake db:migrate:status.
All migrations should display up.

To rerun a migration, you can use zammad run rake db:migrate VERSION=20201006131231.
Your main issue will be that you have blocking migrations if you’re unlucky.

At least that’s the case in a current 4.0 from the migration point you’re referencing to.
I’d suggest to ensure that all migrations run on the broken system before trying anything else.

I don’t know how you migrated, however, please note that the “how” is absolutely important.
You may want to check the docs if not done already: Backup and Restore — Zammad System Documentation documentation

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.