Open Guilherme2112 opened 4 months ago
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.
@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 š¤
@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)
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 s
commandSteps to reproduce
workers
onconfig/puma.rb
)rails s
Useful info
bundle exec rails s
command, since runningbundle exec puma -t 1:1 -w 1:1
looks finerails c
console, the normal behavior occursExample project
https://github.com/Guilherme2112/flagsmith-rails-example
(basic instructions at README)