mainio / decidim-module-term_customizer

Decidim module that allows customizing the localization terms in the system for specific contexts.
GNU Affero General Public License v3.0
15 stars 21 forks source link

Intermittent Failure of Term Customization Under Multiple Process and Component Constraints #107

Open simonaszilinskas opened 1 year ago

simonaszilinskas commented 1 year ago

Expected Behavior: When applying multiple process and component constraints, terms changed through the Term Customizer should update consistently across the application.

Actual Behavior: When multiple process and component constraints are applied, Term Customizer intermittently fails to update terms, causing inconsistencies.

Quentinchampenois commented 1 year ago

Hello, to add more information

We notice some inconsistencies on TermCustomizer I18n translations, for example : On the proposals index, proposal states have been updated using the Term Customizer with different constraints.

On the filter section, I18n translations switches from Default translation, Good TermCustomizer Translation, and Other constraint Term Customizer. So on each request you can have one of these three translations.

This is a tricky issue because I think this is not only related to the term customizer but also to the Decidim's caching and maybe to the current infrastructure.

Also, some inconsistencies may be related to the rails caching (for example: Translating the proposal state does not invalidate the proposal card cache key)

Here is some screenshots of different behaviours for a same page (screenshots from platform : https://oye.participer.lyon.fr/processes/bp2022/f/64/)

We are currently investigating on it, my concern is that it might by related to #93

ahukkanen commented 1 year ago

Just to rule out the caching issue, I would suggest manually clearing the cache on every Decidim thread that you have running in production.

The cache clearing functionality available at the Term Customizer dashboard only clears it for the current thread that happens to be serving your request. This works fine on a single server configuration when the threads are using file system caching that is common for every thread.

If the caching is per-thread (e.g. if using file system cache + multiple different containers/machines), you have to clear the cache for every thread manually. It can be also addressed with a configuration change, i.e. using a centralized caching system for all threads.

Quentinchampenois commented 1 year ago

Thank you for these points, I am currently investigating the multi-threading part

I reproduced the issue with a Decidim application running on Puma with 5 threads / 1 worker and Memcached I did not reproduced with 1 thread / 4 workers and Memcached

Parts of my investigations :

Not sure for now, I continue the investigation

BigSnicker commented 9 months ago

We're encountering quite a few issues with this in our implementation.

We are using customized terms for voting processes and participants are getting confused by the original terms suddenly appearing in a fairly random manner. Let us know if we can help, but he problem is hard to reproduce consistently.

simonaszilinskas commented 9 months ago

Hello @BigSnicker , we did a partial fix on this branch of this fork: gem "decidim-term_customizer", git: "https://github.com/opensourcepolitics/decidim-module-term_customizer.git", branch: "fix/multi-threading-compliant-0.26"

We also spec'ed and financed a development for custom proposal state creation (that's where we used term customiser the most) as a module: https://github.com/alecslupu-pfa/decidim-module-custom_proposal_states