Open therabidbanana opened 1 year ago
Hi @therabidbanana sorry for missing this issue.
Could you validate that my warning in PR #42 is accurate?
That sounds right - added a comment with a bit more detail.
Thanks! I'll keep this issue open to track that this still needs to be updated.
I set up AmplitudeExperiment with LocalEvaluation in a Puma environment, calling
#start
on the client during Rails initialization.Expected Behavior
Each worker process is able to see updates to flag configuration or error is logged alerting you to dead polling thread and potentially stale results.
Current Behavior
No errors are raised, but the flag configurations are not updated after processes fork and so the flag configurations become stale even though logs show polling behavior happening.
It appears to be that the polling thread is dead when logging from the worker, but the thread is still active in the main process and logging updates (with the logger fix from #38) , which is misleading.
Captured below - we see a fetch of flagVersion 17 but then a few seconds later when inspecting the experiment client we see it is stuck at 16 and poller_thread shows status of
dead
in the inspect:Possible Solution
Either documentation to describe how to achieve expected behavior (you must call
#start
after process fork), or better handling of this case to automatically achieve desired behavior (example from Redis client watches a cached @pid variable to detect a fork: https://github.com/redis-rb/redis-client/commit/bec4931c952b6196c76977356238dbaf4f2e1293 )Environment