Improve app restart handling (after object field related schema changes)

[mgruner]

Used Zammad Version

6.3

Environment

• Installation method: all
• Operating system (if you're unsure: cat /etc/os-release ): all
• Database + version: all
• Elasticsearch version: irrelevant

Actual behaviour

When making changes to core objects like adding new Ticket fields, schema changes in the database have to be executed. After that, a restart of all application server processes is needed. This can be automated on package and source installations (via APP_RESTART_CMD), but does not work in containerized environments (hacks are possible for docker, but go against security considerations).

Additionally, for the manual restarts, there is a time of inconsistency when the schema was already changed, but processes like scheduler not yet restarted - which can lead to inconsistent behaviour.

Expected behaviour

Zammad should be changed in a way that these restarts are either not needed, or work correctly on any installation method in an automated way, reducing times of inconsistent code state to a minimum.

Steps to reproduce the behaviour

• Install Zammad on kubernetes
• Create a new ticket field and apply the database changes
• Now you need to redeploy the app on Kubernetes manually

Support Ticket

No response

I'm sure this is a bug and no feature request or a general question.

yes

[mgruner]

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 it in the migrations.

If Restart is Required

We could consider informing all processes about a required change (e.g. through a hidden setting with a number that is incremented). All processes will detect such a change and respond to it by terminating. It's the responsibility of the process manager (systemd, docker compose, kubernetes) to bring up new processes instead.

If Reload is Enough

All processes are notified about the change (see above), but they don't terminate but instead only refresh their model data and other relevant parts of the API on the back end side. The new mobile and desktop front ends don't need a restart anyway, legacy app still needs a browser reload.

[dominikklein]

The new mobile and desktop front ends don't need a restart anyway

Why do you think the new stack needs no reload?

[mgruner]

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

[dominikklein]

No, because form fields are build based on the object attributes which are returned from the server. And the attributes are fetched once. So after a new attribute was added/changed it's no longer up to date from this perspecctive. For sure we could add some subscription for that, but at least it's currently not implemented.

[mgruner]

Ok, but that would work without a full app reload, hopefully.