Martin Gruner

Summary from customer session: customer uses an external postgresql service, plus forked background worker processes. It seems that Zammad does not correctly handle the case when a worker process dies...

We believe that the fixes for #5513 and also https://github.com/zammad/zammad/commit/b5141f6670920bd960ab4269dc80b1d09d7c8eb6 will solve the issue or at least improve the situation significantly with Zammad 6.5 (coming soon). I'll close this report...

@0xalen thanks for your report. Could you please post your `database.yml` configuration file (without the password, of course)? You can try to debug this yourself on a running system without...

@yogo1212 we can only work on this if there is a reproduction path to follow. We don't see this problem on our systems yet. Therefore I'll close this report now....

> Nice tool :) > > Do you plan to automate this via the Github action too? https://github.com/updatecli/updatecli-action Not right now, but probably later on. BTW I had to remove...

@monotek I updated again to the latest Zammad patchlevel. This new image drops the unneeded node_modules folder, is thus much smaller and I hope the security scanner on artifacthub will...

@monotek could you approve this please?

@mueller-ma we use renovate for Zammad already, but not for the helm stuff yet. Do you have an example or documentation for this specific usage? I didn't find something useful...

## Ideas We should evaluate first if the restarts are actually required, or if on the server a refresh of the model objects (`reset_column_information`) would be sufficient, like we do...

I was under the impression, because our graphql schema is static and does not change based on the object fields. Is that not correct?