📣

Resilire Tech News 2025/11/07 - Tech NewsとTanStack Query Retry

に公開
resilire
technews
idea

サマリー

こんにちは、今週のResilire Tech Newsへようこそ。今週のホットトピックは大きく2つ。「社内のエンジニアMTGの議論を起点に、AIで定期ブログ発信する仕組み」を試験運用する話題とフロントエンドのHTTP再試行（TanStack Queryのretry）に関する議論です。
コーヒー片手にさっとチェックしていきましょう！

注目ポイント

  • Resilire Tech Newsという、社内のエンジニアMTGの議論を外部向けに定期配信する仕組みを作る試みを始めました

    • 自動化ツールで毎週金曜に社内のエンジニアMTGの該当スレッドを取得 → AIがラジオパーソナリティ風に記事化 → レビュー用の下書き（PR）を自動作成 → 社内レビューを経て月曜昼に公開という仕組みでお届け

  • TanStack Queryのretry（デフォルト挙動）をデフォルトでオフにする提案

    • メリットは「重いSQLの意図しない再実行を防ぐ」、デメリットは「ネットワークの一過性エラーでUXが悪化する場合がある」こと
    • 404や400系など、明らかに再試行が不要なステータスはリトライ除外にするという実務的な妥協案

社内MTGでの様子

Resilire Tech News

  • 自動化と人的レビューのハイブリッド
    • 自動でドラフトを作ることで継続的な社外発信負荷を下げつつ、PRベースのレビューで品質と機密管理を担保する流れがポイント
    • 公開する情報の詳細レベルについては調整が必要
    • 現段階では、第一弾としてResilire Tech Newsを始めつつ、都度調整していこうとなった

TanStack Queryのretry処理

まずはフロントエンドエンジニアから「なんでdefaultがretryなんだろう？」と誰かがつぶやき、波紋が広がりました。

TanStack Queryは便利ですが、再試行が裏目に出るケースもあると指摘が多数ありました。

たとえば：

  • エラーハンドリングが雑な実装だと、404でも時間をあけてずっとリトライし続ける危険がある
  • 重いSQLを実行しているAPIがリトライされると、負荷増加やタイムアウトの悪循環を招く
  • 一方で、ツリー表示などキャッシュを使いつつUXを良くしたい画面ではretryが助けになる場合もある

結論に近い空気としては、デフォルトretryをオフにして、必要な画面だけで明示的にretryを有効化する方針にしたようです。

その際に、以下を検討しているようです：

  • まず開発環境で切って観測し、Sentryやクラウドのログでリトライの頻度と影響を計測する
  • 400系（クライアントエラー）はリトライ対象外にする設定を検討する
  • リトライ時のリクエストにカスタムヘッダをつけてログ側で追跡できるようにする

最後に

技術発信を"続けられる仕組み"にする試みは、採用の入り口としても、社外にResilireらしさを伝える良い機会です。今回の案は自動化で手間を減らしつつ、人の目で品質と機微を守るハイブリッド運用が肝ですね。

Resilireはエンジニア採用を積極的に行っています。興味がある方はぜひ募集ページをご覧ください：
https://careers.resilire.jp/

それでは、また次回のテックニュースでお会いしましょう。ご意見や「ここもっと詳しく！」というリクエストがあれば歓迎です。

Discussion