Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#2,965 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
56/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
rails, ruby
Bereich
backend, performance, testing

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Ruby
Sterne
106
Forks
208
Ø Merge
19 Std. 31 Min.
Gemergte PRs (30 T.)
84

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus codebar/planner

Alle Issues in codebar/planner

Ähnliche Issues

Weitere Issues zu Ruby

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.