Rails apps with puma on cluster mode not catching up flag changes when local evaluation is enabled

[Guilherme2112]

Context

When the following conditions are met, the local environment of the rails server does not refresh the flag states...the environment document request actually happens, tough.

• rails app
• puma (on cluster mode - even with 1 worker 1 thread)
• local evaluation enabled
• booting with rails s command

Steps to reproduce

• Create a new rails app
• Configure puma with cluster mode (set a value above zero for workers on config/puma.rb)
• Create an initializer, defining the global variable, just like the documentation shows. Local evaluation must be enabled
• boot the server with rails s
• check if the flagsmith client is responding to flag state changes on the flagsmith dashboard between every environment document request

Useful info

• Works normally with puma on single mode
• Puma worker and thread count does not matter to the issue
• On puma cluster mode, it seems like there is something wrong with the puma boot using the bundle exec rails s command, since running bundle exec puma -t 1:1 -w 1:1 looks fine
• Worth mentioning that the local evaluation on the rails c console, the normal behavior occurs
• Tested on macOs Ventura 13.6.7 (M1 chip) and Ubuntu 22 (x64)

Example project

https://github.com/Guilherme2112/flagsmith-rails-example

(basic instructions at README)

[zachaysan]

Thanks for the well written issue @Guilherme2112. It's not immediately clear to me as to why this would happen and I've sadly never used Puma before. Do you have any guesses or insights as to what would cause this? My initial suspicion would be some sort of threading issue, but I'm really only grasping at straws here.

[Guilherme2112]

@zachaysan I also believe it is some kind of threading issue, but I can't pinpoint what it is...I would bet on something related to the puma child process forking and the rails initialization...app preload may play a role too 🤔

[Guilherme2112]

@zachaysan what I managed to do to get around the problem was to create a singleton class containing the client and only call for an instance when needed...this way there was no interaction between puma threads and the flagsmith client (likely the background polling thread or the mutex part)

And to my surprise, it looks pretty close to what the competitor does (😅) , so it may be pointing towards a solution?

(edit: english is not my mother tonge so here's a disclaimer if the tone sound inapropriate, I don't mean to)