Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

EventCardComponent fragments key only on the event record — listing pages can render stale sponsor/venue content

オープン
  • 何か問題がありますか？
#2,965 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
56/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
rails, ruby
領域
backend, performance, testing

調査の方向性

Start at app/components/event_card_component.html.erb:1 and inspect how listing pages eager-load venue/host, sponsors, and organisers, using the chapter caching work in #2952 as a reference. Add coverage for renaming a sponsor without touching the event row, then verify the card shows the new name and that payload.allocations p50 does not regress.

索引モデルが issue の本文から書いたものです。

説明

Event card fragments go stale when sponsors/venues/organisers change without touching the event row

Summary

EventCardComponent fragment-caches itself with the key [@event.cache_key_with_version, I18n.locale, :v2] (app/components/event_card_component.html.erb:1). The key tracks only the event record. The card also renders @event.venue (workshops: the host sponsor through the scoped workshop_host join), @event.sponsors, and @event.organisers — and none of those records touch the event's updated_at when they change.

So renaming a sponsor (or swapping a venue, or adding an organiser) leaves every cached card intact until the event row itself changes. On pages where the event row is touched often this heals quickly; on listing pages it can persist for weeks.

Observed in the #2964 review (chapter show): the page ETag rotated correctly on a sponsor rename, the sponsors-section fragment busted, and the event card still showed the old sponsor — a fresh 200 with mixed stale/fresh content. Probed at runtime with perform_caching = true.

Scope

  • Pre-existing on master: every page rendering the component (homepage upcoming list, /events/upcoming, chapter pages, dashboard) shares the gap.
  • PR #2964 (chapter show caching) narrows the exposure for anonymous visitors — the new page ETag includes the card-rendered records, so repeat anonymous visitors revalidate to a fresh 200 — but the card fragment itself still serves the old body after that 200, and logged-in members (who bypass the ETag) still get stale cards until the event row changes.

Suggested directions

  1. Widen the card fragment key to include the card-rendered records: venue/host, sponsors, organisers (plus the locale/bump token, bumping :v2 to a new version). Caveat: pages that do not eager-load those records would trigger extra queries per card just to compute the key — the homepage and events pages need their eager loads reviewed in the same change (same shape as the chapter fix in #2952).
  2. Alternative: drop the card fragment entirely on pages that already cache the page or section — the chapter page no longer needs it once the ETag gates renders.

Direction 1 is preferred; direction 2 can be a stopgap for specific pages.

Verify

  • Spec: rename a sponsor without touching its workshop/event row, re-render a listing page, and assert the card shows the new name (fails on current key).
  • payload.allocations p50 for the affected listing controllers must not regress (the wider key adds cache-key computation, ideally query-free via existing eager loads).

Related: #2952, #2951 (same measurement method and caching recipe); review run recorded on PR #2964.

主要言語
Ruby
スター
104
フォーク
205
平均マージ
1日 4時間
マージ済み PR（30日）
77

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

codebar/planner のほかの issue

codebar/planner の issue をすべて見る

似ている issue

Ruby の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。