2020エラー検知・監視ツールであるところのSentryが提供するRubyのSDKにsentry-ravenというgemがあります。このgemを利用するとごくわずかなコードの記述をするだけでSentryに対してイベントを送信することができます。イベントにはユーザーが定義したカスタムタグや実行環境を含む多様な情報を含めることができ大変便利です。data")end上述のようなコードを見た/書いた方も多いと思います。本件が意図した挙動なのか不明だったので本体にレポートしまして、トリアージ待ちです。本件の行く末が気になる方はissueをウォッチしていただければと思います。github.comまた、sentry-ravenはすでにアクティブな開発が停止しており、sentry-rubyやsentry-railsに移行するようアナウンスがされています。僕が遭遇したプロジェクトでもこの問題による不具合を契機としてmigrationを実施しています。破壊的に書き換えられます。%w[quite_sensitive_field]end後継のsentry-rubyでは起きない?はい。sanitization等を行う機構をprocessorと呼ぶのですが、この機構は後継のsentry-rubyや周辺のgemには存在しません。ruleを登録するようになっています。何が問題かRaven.capture_*に副作用がないと思っていると痛い目を見る...。具体的な例を挙げます。dataを参照できません。RailsのcontrollerやmodelでRaven.capture_*を呼び出し、そのあとでenv["rack.request.form_hash"]を見るようなことがあれば同様にマスクされた文字列になっています。dataはコピーされたものなのでRailsアプリケーション内でparamsを見るふつうの(?)コードを書いていれば途中でRavenを使っても問題ないでしょう。発見の経緯そんなことするか?って思いますかね。middlewareのどこかでうっかりSentryに通知することはあるんじゃないでしょうか。middlewareでOpenAPI定義に違反するリクエストが来たらSentryに記録する(けど後続の処理はそのまま行う)」という使い方でした。最初はユーザーが不正なリクエストをして400になっただけと思ったけど、開発環境でも事象が再現すること、および僕が変更したOpenAPIの定義をrevertすると再現しないことを同僚が発見してくれたのでバグだと気づくことができました。sentry-ravenの実装の詳細Rack::Request#form_data?がtrueのときRaven::RackはRack::Request#POSTを呼び出し、書き換える対象のHashへの参照を得ています。後のRaven::Event#to_hashというメソッドで実行環境の情報をHash化します。このときも同一のポインタをそのまま渡しています。Raven::Processor::SanitizeDataというデータマスクを行うclassにそのHashが渡るのですが、その中でHash#merge!を実行して破壊的に更新をしています。デバグさらっと書きましたが最初は「OpenAPI定義を変更したらリクエストパラメータがマスクされるようになった」ように見えたのでわけがわかりませんでした。configのsanitize_fieldを変更すると再現しない、Sentryへの通知をやめると再現しない、といったあたりまで同僚が絞り込んでくれたので、僕の方ではsentry-ravenのコードを読みながらステップ実行していってようやく原因にあたりがつきました。最小の再現プロジェクトを作る100%再現するバグなら勝利は約束されるので、最小の構成で再現するプロジェクトを作ってみました。appを作り、その中でRaven.capture_*を呼ぶ。envの中身が変わっていることを確認する。味の秘密は、それだけ。"age"=>"32"}%BINGOです。2020の1日目は@ohbaryeが担当しました。Relicを使うあとN+1回寝るとISUCONです。5はてなブログをはじめよう!ohbaryeさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。