You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was bit recently by a bug because a thread (created by a library) did not properly initialize current_store_id. I added a monkey patch to add that, and all is working well now.
However, this got me thinking: why is it possible for current_store_id to ever return nil? I believe the safer default is to always set to SecureRandom.uuid if uninitialized:
The current default basically makes all the spawned threads share a store between them, but separate from the main thread.
It may be an even safer default to raise an error when the request store is unset. It probably means a thread was spawned without proper setup/teardown
The text was updated successfully, but these errors were encountered:
Using SecureRandom.uuid might cover up problems when threads are not properly initialized
A potential problem with raising an error, is that it would stop working in non-request lifecycles (for example, in a console)
A possible solution would be to have the main thread use true unless specified, and raise an error for any child threads that are not explicitly initialized.
Hi,
I was bit recently by a bug because a thread (created by a library) did not properly initialize
current_store_id
. I added a monkey patch to add that, and all is working well now.However, this got me thinking: why is it possible for
current_store_id
to ever returnnil
? I believe the safer default is to always set toSecureRandom.uuid
if uninitialized:The current default basically makes all the spawned threads share a store between them, but separate from the main thread.
It may be an even safer default to raise an error when the request store is unset. It probably means a thread was spawned without proper setup/teardown
The text was updated successfully, but these errors were encountered: