Intermittent Failure of Term Customization Under Multiple Process and Component Constraints

[simonaszilinskas]

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]

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]

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]

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 :

• I18n::Backend::Simple in version 1.14 uses a Mutex for thread safety
• Also I think there could be kind of race conditions in the TermCustomizer engine's hooks on line 30 and 34 and also in TermCustomizer::Backend.translations

Not sure for now, I continue the investigation

[BigSnicker]

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]

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