Update 6.0.0 -> 6.1.0 issues errors: Immediate fix required or can it nevertheless be used?


  • Used Zammad version: zammad-6.1.0-1695625218.7afd377e.centos7.x86_64
  • Used Zammad installation type: yum from repository
  • Operating system: CentOS Linux release 7.9.2009 (Core)
  • Browser + version: Firefox 117.0.1 (macOS)

Problem Description

Today’s yum update zammad printed out two errors, but in the end didn’t seem to (completely) fail. One error was during the database migration(?) step:

== 20230726082734 SMIMEMetaInformationTable: migrating ========================
-- change_table(:smime_certificates)
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:

The other later, apparently during node script/fix-node-modules.mjs:

$ node script/fix-node-modules.mjs
Done in 1.23s.
Building with Vite ⚡️
vite v4.4.9 building for production...
✓ 1954 modules transformed.
[vite-plugin-pwa:build] "default" is not exported by "app/frontend/shared/composables/useImageViewer.ts", imported by "app/frontend/shared/components/Form/fields/FieldFile/FieldFileInput.vue?vue&type=script&setup=true&lang.ts".
file: /opt/zammad/app/frontend/shared/components/Form/fields/FieldFile/FieldFileInput.vue?vue&type=script&setup=true&lang.ts:24:7
22: import type { FormFieldContext } from '#shared/components/Form/types/field.ts'
23: import { MutationHandler } from '#shared/server/apollo/handler/index.ts'
24: import useImageViewer from '#shared/composables/useImageViewer.ts'
25: import { convertFileList } from '#shared/utils/files.ts'
26: import useConfirmation from '#mobile/components/CommonConfirmation/composable.ts'
error during build:
RollupError: "default" is not exported by "app/frontend/shared/composables/useImageViewer.ts", imported by "app/frontend/shared/components/Form/fields/FieldFile/FieldFileInput.vue?vue&type=script&setup=true&lang.ts".
    at error (file:///opt/zammad/node_modules/vite/node_modules/rollup/dist/es/shared/node-entry.js:2245:30)
    at Module.error (file:///opt/zammad/node_modules/vite/node_modules/rollup/dist/es/shared/node-entry.js:13674:16)
    at Module.traceVariable (file:///opt/zammad/node_modules/vite/node_modules/rollup/dist/es/shared/node-entry.js:14104:29)
    at ModuleScope.findVariable (file:///opt/zammad/node_modules/vite/node_modules/rollup/dist/es/shared/node-entry.js:12547:39)
    at FunctionScope.findVariable (file:///opt/zammad/node_modules/vite/node_modules/rollup/dist/es/shared/node-entry.js:7082:38)
    at ChildScope.findVariable (file:///opt/zammad/node_modules/vite/node_modules/rollup/dist/es/shared/node-entry.js:7082:38)
    at Identifier.bind (file:///opt/zammad/node_modules/vite/node_modules/rollup/dist/es/shared/node-entry.js:8267:40)
    at CallExpression.bind (file:///opt/zammad/node_modules/vite/node_modules/rollup/dist/es/shared/node-entry.js:5850:23)
    at CallExpression.bind (file:///opt/zammad/node_modules/vite/node_modules/rollup/dist/es/shared/node-entry.js:9833:15)
    at VariableDeclarator.bind (file:///opt/zammad/node_modules/vite/node_modules/rollup/dist/es/shared/node-entry.js:5850:23)
    at VariableDeclaration.bind (file:///opt/zammad/node_modules/vite/node_modules/rollup/dist/es/shared/node-entry.js:5846:28)
    at BlockStatement.bind (file:///opt/zammad/node_modules/vite/node_modules/rollup/dist/es/shared/node-entry.js:5846:28)
    at FunctionExpression.bind (file:///opt/zammad/node_modules/vite/node_modules/rollup/dist/es/shared/node-entry.js:5850:23)
    at Property.bind (file:///opt/zammad/node_modules/vite/node_modules/rollup/dist/es/shared/node-entry.js:5850:23)
    at ObjectExpression.bind (file:///opt/zammad/node_modules/vite/node_modules/rollup/dist/es/shared/node-entry.js:5846:28)
    at CallExpression.bind (file:///opt/zammad/node_modules/vite/node_modules/rollup/dist/es/shared/node-entry.js:5846:28)

pid 3399 exit 1
Build with Vite failed! ❌

I don’t know if these errors are related and what their consequence is. Cen they be ignored (I guess not) and how can they be fixed?

The most important and urgent question is: Can we continue to work before possible fixes are applied or does Zammad has to stay closed for the time being?

The complete yum update output is very long. I have provided it here.

1 Like

As the error message says, the current and all following migrations are canceled, so there could be a lot of stuff missing.
So this should be checked/executed again.

About the failing assets precompile. Could you check what are the current files inside app/frontend/shared/components/Form/fields/FieldFile/ ?

Hi Dominik,

What is “this” and how can I execute it again? The process was run through a regular yum update zammad process.

In the meantime we have continued to work with Zammad, as it is an essential part of our operation. We haven’t encountered problems so far and we cannot risk to loose (more?) data.

We have the following content

$ tree -F app/frontend/shared/components/Form/fields/FieldFile/
├── graphql/
│   └── mutations/
│       └── uploadCache/
└── types.ts

3 directories, 1 file

app/frontend/shared/components/Form/fields/FieldFile/types.ts contains:

// Copyright (C) 2012-2023 Zammad Foundation, https://zammad-foundation.org/

import type { StoredFile } from '#shared/graphql/types.ts'
import type { InputHTMLAttributes } from 'vue'

export interface FieldFileProps {
  accept?: InputHTMLAttributes['accept']
  capture?: InputHTMLAttributes['capture']
  multiple?: InputHTMLAttributes['multiple']

export type FileUploaded = Pick<StoredFile, 'name' | 'size' | 'type'> & {
  id?: Maybe<string>
  content?: string
  preview?: string

export interface FieldFileContext {
  uploadFiles(files: FileList | File[]): Promise<void>

Maybe all is fine, you could check in the rails console (rails c) if there are pending migrations with:


When this list is empty, all should be fine.

About the other problem, this seems to be fine already again.

@dominikklein I tried zammad run rails c ActiveRecord::Migration.check_pending and zammad run rails c config:get ActiveRecord::Migration.check_pending. Both returned

/opt/zammad/vendor/bundle/ruby/3.1.0/gems/thor-1.2.2/lib/thor/base.rb:525:in 'handle_argument_error': ERROR: "rails console" was called with arguments [...] (Thor::InvocationError)

and a call trace (which I can post if it is relevant). I assume this is the wrong syntax :slight_smile: Can you help out with the full command that is required to check ActiveRecord::Migration.check_pending?

You’re doing it wrong, @fthommen.

Please open up a Rails Console via zammad run rails c. After the Rails Console is ready to use, please submit following command: ActiveRecord::Migration.check_pending!

Post the output here, please. :slight_smile:

yes, I guessed so :grin:, but I just get an other error:

$ zammad run rails c                                            
Loading production environment (Rails                                          
irb(main):001:0> ActiveRecord::Migration.check_pending
-- check_pending()
/opt/zammad/vendor/bundle/ruby/3.1.0/gems/activerecord- `block in method_missing': undefined method `check_pending' for #<ActiveRecord::Migration:0x00007efd38829088 @name="ActiveRecord::Migration", @version=nil, @connection=nil> (NoMethodError)                                                     
irb(main):002:0> quit

@fliebe92 Oops, it seems the exclamation marks are part of the command?

$ zammad run rails c
Loading production environment (Rails
irb(main):001:0> ActiveRecord::Migration.check_pending!
/opt/zammad/vendor/bundle/ruby/3.1.0/gems/activerecord- `check_pending!':  (ActiveRecord::PendingMigrationError)

Migrations are pending. To resolve this issue, run:

        bin/rails db:migrate RAILS_ENV=production

You have 11 pending migrations:


irb(main):002:0> quit

would these instructions translate to “run zammad run rails db:migrate RAILS_ENV=production”? (I rather ask before breaking somethin…)

i had the same migration error on debian, but i thought the error on my selfmade migration of mysql to postgres a few years ago.

in my case was the problem in 20230726082734_smime_meta_information_table.rb
It describes to remove the index “subject”.
The named index “subject” was not present in my postgrsql tablestructure.

So i removed the following migration definition and rerun the migration.

I checked the database after migration with adminer (https://www.adminer.org/) and everything looks good.

Mayby you run in the same problem.

at this time, it seams that no one else had this problem and so i didnt create a issue-ticket.