Persistent Issues with Missing Tables and Links – How Can Users Get Support?

[markusthiel]

Hello everyone,

At first, I was actually quite enthusiastic about this system because I was hoping to find something flexible that I could perfectly adapt to our needs. Unfortunately, I now have to completely discard the entire installation once again, as there are simply too many errors that I cannot handle without support. And that support is rather limited here. Since many others are struggling with the same issues, it might be time to address some common problems and provide comprehensible guidance.

What keeps happening are missing tables, missing links, and missing table columns. I recently set up a new system with v.41, and after updating to 42, nothing worked again. (relation "workspace_3721ymu0vgv4cznrw0n3rn93v.workflowVersion" does not exist, relation "workspace_3721ymu0vgv4cznrw0n3rn93v.workflowVersion" does not exist, column note.createdByContext does not exist)

How can the many users facing these issues be helped?
Can the missing elements be created manually? Are these just unavoidable problems due to the system still being in an early alpha stage? It would be great to get some information on how long one should generally wait before the system becomes stable and usable (aside from minor bugs, which always exist).

Best regards, and thanks in advance for your response!

[sommarnatt]

I've run into several bugs/issues as well. I'd say it's better to stay on the next to last version until there is a new one out.
Also when upgrading, it seems better to upgrade to the latest patch release, since at least twice ive run into issues where I've had to restore DB when upgrading to a .0 patch release.

[FelixMalfait]

Hey @markusthiel sorry for this. Improving the upgrade experience is one of our top priorities along with workflows/permissions. The upgrade process is quite complex compared to other softwares due to the fact that each workspace can have a different schema. We've had to build a lot of custom tooling to manage this. It works well for us internally but for someone outside it's too difficult to figure out.
We've started building an admin panel that should will make the install/upgrade experience a lot smoother. Right now there isn't much in it, but I would say that by end of March / early April it will start becoming a lot easier to upgrade or to diagnose when something is wrong.

Related to @sommarnatt's command I think we also need to change our deployment process. Right now deploying the .0 is the first step before we attempt a cloud deployment and we publish subsequent fixes if it failed for any workspace. We plan to setup a staging environment with production data because there are edge cases in data migration that doesn't appear with seed data. We also might need to review the way we name that first version, maybe introduce "RC" concept.

[markusthiel]

Thanks for the info!

If I understood correctly, I can switch back and forth between updates within a major version. Only when upgrading to a new major version do I need to be careful due to database changes, is that correct?

That already gives me some clarity. In the last version, the entries in the tables were no longer clickable. I rolled back a few sub-versions, and now the system is running again, and I can click on the data again.

Until now, I was afraid of breaking even more if I tried another update on top of a faulty one.

Maybe it makes sense to announce "breaking changes" in the release notes - especially those that prevent rolling back easily.

Many thanks and keep up the great work! It will be perfect once the teething issues are under control.

[FelixMalfait]

If I understood correctly, I can switch back and forth between updates within a major version. Only when upgrading to a new major version do I need to be careful due to database changes, is that correct?

Yes that's correct, or at least that's what we aim for!

Maybe it makes sense to announce "breaking changes" in the release notes - especially those that prevent rolling back easily.

Yes our strategy has been to do all the breaking changes as soon as possible to hopefully get a more stable system as soon as possible. But they are still things we need to build that will change the API unfortunately, for example the way we manage attachments or polymorphic relationships will evolve, it was too hard to build correctly at first. But we're slowly getting there...
I have a lot of hope for the improve auto-upgrade process, we're getting started on that (e.g. small detail I just introduced a version column to track what the last update was which will help the script to be more intelligent #10451)