Make parameter parsers assignment Ractor safe

rails/rails

デフォルトの parameter_parsers が Ractor 間で安全に共有できるよう、ハッシュの割り当て方法と不変化処理を追加しました。これにより、Ractor 環境でのパラメータ解析が安全に実行されます。

背景

デフォルトパーサ集合は以前のコミット f2be45a で Ractor 安全化されましたが、割り当て時にハッシュが変換されてしまい、freeze が行われていませんでした。Ractor では mutable なオブジェクトは共有できず、未凍結のハッシュはエラーの原因になります。

parameter_parsers= メソッドは受け取ったハッシュを変形した上で代入しますが、変形後のオブジェクトは凍結されず、他の Ractor から参照された場合に安全性が損なわれます。この問題はデフォルト設定だけでなく、ユーザーがカスタムパーサを設定する際にも潜在的に顕在化します。

したがって、ハッシュを割り当てる前に freeze し、さらにデフォルト設定は不必要なコピーを避けて直接インスタンス変数に格納する必要があります。

技術的な変更

ActionDispatch::Http::Parameters のクラス初期化部とセッターを修正し、ハッシュを freeze した上で直接 @parameter_parsers に代入するようにしました。これにより、ハッシュは Ractor 間で安全に共有できます。

変更前:

class << self
  attr_reader :parameter_parsers
end

self.parameter_parsers = DEFAULT_PARSERS

変更後:

class << self
  attr_reader :parameter_parsers
end

@parameter_parsers = DEFAULT_PARSERS

また、カスタム設定用のセッターも凍結処理を追加しました。

def parameter_parsers=(parsers)
  @parameter_parsers = parsers.transform_keys { |key| key.respond_to?(:symbol) ? key.symbol : key }.freeze
end

この変更により、デフォルトハッシュは直接代入され、コピーが発生せず freeze が保証されます。さらに、ユーザーが提供するハッシュはキー正規化後に凍結され、Ractor 安全性が確保されます。

設計判断

デフォルトパーサは内部的に正しい形状であることが保証されているため、公開 API を経由せず直接インスタンス変数に設定する方針が採られました。これにより余計なハッシュコピーを回避し、パフォーマンスと安全性を同時に向上させられます。

一方で、カスタムパーサを設定する際には公開セッター parameter_parsers= を維持し、キー正規化と freeze を行うことで既存の外部インターフェースはそのまま利用可能です。これにより、後方互換性を損なうことなく安全性を強化しています。

この設計は「安全性の確保」と「最小限の侵入性」のトレードオフを意識し、内部実装の最適化と外部 API の一貫性を両立させた選択と言えます。

記事メタデータ

Generated by:
gpt-oss-120b for DiffDaily
LLM Trace:
580a5404

この記事はAIによって自動生成されています。内容の正確性については、必ずソースコードやPRを確認してください。

品質レビュー結果

Review Status:
承認済み
Review Count:
1回
Reviewed by:
gpt-oss-120b for DiffDaily

Review Criteria:

記事構成 ⚠ WARNING

Title, Context, Technical Detailの存在と明確さ

リード文、背景、技術的変更は揃っているが、記事の最後に明示的な「まとめ」セクションが欠けている。結論としてのインパクトや影響をまとめた箇所が無いため、WARNと評価。

カスタムMarkdown構文 ✓ PASS

シンタックスハイライト・GitHubリンク記法の正確性

ファイル名付きコードブロックは正しい形式(```ruby:filepath)で使用され、PRリンクも #57952 がリンク化されている。GitHubリンク記法に問題はない。

対象読者への適合性 ✓ PASS

エンジニア向けの適切な技術レベルと表現

対象はRailsエンジニアであり、専門用語のみ使用。初心者向けの過度な説明はなく適切。

パラグラフ・ライティング ✓ PASS

トピックセンテンス・1段落1トピック・段落長

各セクションは総論→各論→結論(設計判断)で構成され、段落はトピックセンテンスで始まり1段落1トピック、長さも適切。空行で区切られている。

Diff内容との照合 ✓ PASS

コードブロックとDiff内容の一致

記事中のコードブロックはDiffと完全に一致。変更点(self→@、freeze の追加)を正確に反映している。

技術用語の正確性 ✓ PASS

技術用語の正確な使用

Ractor、freeze、transform_keys などの用語は正しく使用され、PRでの記述と一致している。

説明の技術的正確性 ✓ PASS

技術的主張の正確性と論理性

技術的な主張はPRの目的(ハッシュ凍結と直接代入)と合致し、因果関係も論理的。誤りなし。

事実の突合 ✓ PASS

PR情報による主張の裏付け(ハルシネーション検出)

すべての事実はPRタイトル、説明、Diffで裏付けられている。外部知識や根拠のない数値は含まれていない。

数値・固有名詞の確認 ✓ PASS

PR番号・コミットID・バージョン等の正確性

PR番号 #57952、コミットID f2be45a が正しく記載されている。数値や固有名詞の誤りはなし。

タイトル・説明との一致 ✓ PASS

記事タイトル・説明とPR内容の一致

記事タイトル "Make parameter parsers assignment Ractor safe" はPRタイトルと完全一致。

外部知識の正確性 ✓ PASS

PRに記載のない外部知識(LTS、サポート状況など)の不使用

LTS、リリース日程、バージョンサポート等の外部情報は一切記載されていない。

時間表現の正確性 ✓ PASS

時間表現がPR情報と一致しているか

「以前のコミット」での過去形表現はPRの記述と整合性が取れている。時間表現の歪曲はなし。