Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#2,965 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
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 小时
30 天内合并 PR
77

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

codebar/planner 的其他 Issue

查看 codebar/planner 的全部 Issue

相似的 Issue

更多 Ruby Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。