このバグは、こちらの投稿からしばらく前に修正されたようです。Custom_fields simultaneous save with json becomes an array
残念ながら、現在はユーザーのカスタムフィールドを同時に更新する複数のエンドポイントが呼び出され、私が :text として設定した値が配列に変換されてしまう問題に直面しています。

ご助言をいただけないでしょうか?この問題が現在、私のプロジェクト全体をブロックしています。
ローカル開発環境の 2.5.0.beta7 でこの問題が発生しています。
この状況で、値が保存されるまでデータベースにロックをかける方法はありますか?
「いいね!」 1
これが私が直面している問題でしょうか? Differences between transactions and locking - makandra dev
2 つのトランザクションが 2 つのスレッドで並行して実行される場合、各スレッドは、トランザクションが正常にコミットされるまで、他のトランザクションの変更を認識しないことに注意してください。ただし、自らの変更は認識します(これは簡略化された説明であり、実際にははるかに複雑です)。
「いいね!」 1
def self.cast_custom_field(key, value, types, return_array = true)
通常の値が表示されるため、複数の行が作成されたのではないかと考えられます。
「いいね!」 2
はい、確認しました 
残念ながら、同時に機密データの更新を行うことになってしまいました。これはエンドポイント経由で行っているためだと考えていますが、これが唯一の方法であり、呼び出しを制御することができません。呼び出しは1回の場合もあれば、10回の場合もあります。
アプリからの呼び出しを最小限に抑え、一部のデータをバッチ送信することは可能ですが、問題なのは呼び出しのソースが2つあることです。それはモバイルと外部サービスです。
支払いデータも関わっています 
「いいね!」 1
eviltrout
(Robin Ward)
6
これは、カスタムフィールドの既存の動作に合致しており、リグレッションではないようです。これを修正する方法はいくつかあります。
- カスタムフィールドに (name, user_id) のユニークインデックスを追加する
- コードを DistributedMutex で囲む
- カスタムフィールドではなくテーブル設計を使用する
「いいね!」 3
こんな感じでしょうか?動作しているようです。
DistributedMutex.synchronize("user_data_update_#{user.id}") do
user.save_custom_fields(true)
end
「いいね!」 1
さらに、すべての呼び出しを一度に実行するのではなく、1 つずつ実行するようにロジックを変更します。これにより、問題の発生を防げることを願っています。
ありがとう @eviltrout @fzngagan
「いいね!」 4