Sentryにエラーレポートが送信される手前でなにかやりたい、あるいは200KB制限によるレポートロストの回避

タイトルどおり。 アプリケーションでエラーが出た場合にSentryにエラーレポートを飛ばしていたのだけど、送信する手前でなんかごにょごにょやりたくなったので調べた。

beforeSend

Sentryのドキュメント、ものすごく目的のものを見つけづらい。

docs.sentry.io

やりたいことはこのDocsに書いてあるとおりで、Sentry.initする際の引数のオブジェクトにbeforeSendがある。

import * as Sentry from '@sentry/browser';

Sentry.init({
  beforeSend(event, hint) {
    console.log(event);
    console.log(hint);
    return event;
  }
});

eventはSentryに送られるレポートのデータが入っている。idとかデバイス名とかなんやかんや色々。ようはレポート上で見れるデータがこれ。

hintは発生したオリジナルのエラーexception。

beforeSend関数で返したeventオブジェクトが最終的なSentryレポートになって、nullを返すとこのエラーレポートは破棄される。

なにをやりたかったか

Sentryに追加で送信する任意のデータの枠にextraという概念がある。Sentry.setExtraあるいはSentry.setExtrasでセットできる。

docs.sentry.io

で、ここにバンバン必要なレポートデータを詰めていくと便利なのだけど、Sentryは1レポート200KBの制限があってこれを超過するとエラーレポート自体が送信されないという問題がある(つまりエラーが起こったことがわからない)。厳密にはSentry側が課している成約というよりはFetchとブラウザの仕様らしい。

エラーデータは動的なのでケースバイケースで200KB超過してしまってエラーレポートがもみ消されたりしていては困るので、Sentryに送信する前にデータサイズを見て、データをなんとかして200KB以下に抑えたかった。

Reduxのトラッキングを送信するケース

具体的にextraになにを入れたかったかというと、Reduxのstateの一部だったりdispatchされたactionをレポートに添えたかったというニーズがあった。

github.com

これはRedux middlewareのライブラリで、ReduxサイクルのトラッキングをしてSentryのextraにReduxの操作を突っ込んでくれる便利なライブラリ。

外部依存モジュールなしの素朴なjsファイル1枚だけのmiddlewareなのだけど、自前で用意するよりうまくできているので、これを突っ込んでおくだけでいい感じにReduxのトラッキングをしてくれて便利。

ただSentryのドキュメントで「stateは大きいかもしれんからextraに突っ込むなら気をつけて」的な言い回しがあり、実際このライブラリを使うとケースによっては200KBを超えていく可能性がある。

そういうわけで前述beforeSendで200KB超えた場合の処理をしたかったという経緯がある。

ちなみにサイズを測るには

beforeSendでサイズを見るには第1引数のeventのサイズを見ればよくて、npmライブラリだとこの辺が使えると思う。

www.npmjs.com

www.npmjs.com

200KB=200000byteなので、200000byteを超えてたら諦めてよさそうなデータを削るとかそういう作戦をとれる。


ようはbeforeSendでSentryに送信されるレポートデータを加工したりできて、いい感じにやれるというはなし。

Auto AssignでPullRequestのreviewers, assigneesを自動割り当てする

チームのGitHubリポジトリへPRを出すときに毎回ポチポチReviewerとAssigneeをクリックするのがダルすぎたのでなんとかしたくて設定した。

要求事項としては

  • 対象のリストのメンバーの全員をPRが作成されるたびにreviewerに自動アサイ
  • PRのassigneeにはPRの作成者が自動アサイ

これを実現したかった。

Auto Assign

probot.github.io

GitHub - kentaro-m/auto-assign: 🤖 A Probot app that adds reviewers to pull requests when pull requests are opened.

Auto AssignはGitHub連携して使用するBotツールで、めちゃくちゃ便利な最高のツール。

使い方はREADMEに書いてあるとおりで、GitHubリポジトリにAppをインストールして、.github/auto_assign.ymlを置いてconfigを書けばOK。

code-owner, Pull Assignerではダメだったのか?

code-owner

GitHubはコードオーナーの設定ができる。

help.github.com

これを設定しておいてPRを作成すると、自動でコードオーナーがReviewerに設定される。

一見これでよさそうではあるのだけれど問題があり、コードオーナーの権限は与えたくないメンバーがおり、しかしそういったメンバーにもPRが出されたら自動でreviewersに設定されて欲しいという欲求があったので、コードオーナーではダメだった。あとAssigneeの設定もできない。

Pull Assigner

pullpanda.com

GitHubに買収されたPullPandaのプロダクトラインの一つがPull Assigner。これも上記コードオーナーかリポジトリのチームメンバーを対象に自動でReviewerを付与してくれる。

特徴は”ランダムに”という点で、ランダムにreviewerを選出してアサインしてくれるので、属人性を防ぐ運用という観点で利用するならこれでOK。

ただ、僕の欲求はランダムであることはむしろ邪魔で、毎回リストメンバー全員を自動アサインしたかったので、ランダムに選出されPull Assignerは要求にマッチしなかった。Configをみたけれど、ランダム選出機能は現在はOFFにできないようだったのでこれもNGだった。

というわけでAuto Assignが適していた

  • リストのメンバーを全員自動アサイ
  • PR提出者をassigneeに自動設定

これを実現する.github/auto_assign.ymlの例は以下。

# Set to true to add reviewers to pull requests
addReviewers: true

# Set to author to set pr creater as assignee
addAssignees: author

# A list of reviewers to be added to pull requests (GitHub user name)
reviewers:
  - member1
  - member2
  - member3
  - member4
  - member5

# A number of reviewers added to the pull request
# Set 0 to add all the reviewers (default: 0)
numberOfReviewers: 0

# A list of keywords to be skipped the process that add reviewers if pull requests include it
skipKeywords:
  - wip
  - bump
  • addAssignees: author にすることでPR提出者を自動でAssigneeに設定できる
  • reviwersに自動アサインしたいメンバーはGitHubネーム@hogehoge@なしで指定
  • numberOfReviewers: 0にすることでリスト全員を対象にできる
  • skipKeywordsにはAuto Assignが反応してほしくないPRタイトルを含むワードを指定する
    • dependabotのPRは反応してほしくないので、bumpを入れている

僕の今回の用途では使わなかったけれど、Auto AssignはPullPandaのPull Assignerと同じくランダム機能があり、numberOfReviewersで数を指定するとその数をランダムにピックして自動アサインしてくれるらしい。リストのグループも作れるみたいなので、ある程度メンバーが多いチームでやるならなお便利だと思う。

その他の詳しいconfigはAuto AssignのREADMEを読むとわかる。

自動でBotがPRをいい感じにしてくれて最高になった。