[cycomachead]

Problem

/calendar.ics?full=1 and /conferences/:id/schedule.ics are polled by calendar clients and were expensive on our 512 MB dyno. icalendar_proposals called Event#time, #room, #track and #difficulty_level for each event, so query count grew with the number of sessions. /calendar.ics also looked up each conference's program and venue separately.

Fix

• icalendar_proposals preloads what it reads (event type, difficulty level, program, track with room and submitter, event schedules with room) and finds the selected event schedule in memory. The time and room logic is the same as Event#time and Event#room.
• /calendar.ics preloads venue, program and selected schedule for all conferences, and loads rooms with the event schedules (they're used for sorting). It no longer loads speakers and submitters, which the feed never used.
• Both feeds are cached in Rails.cache for up to 12 hours:
  • /calendar.ics: key is the row count and latest updated_at of conferences, programs and venues, plus full/short and the request host.
  • schedule.ics: key is the program, selected schedule, conference and venue cache versions, plus the request host.
  • Events, event schedules, schedules, tracks, event types, difficulty levels and rooms all touch their program (EventSchedule → Schedule → Program cascades). The new specs check that rescheduling a session and editing a venue both invalidate the cache.
  • Neither feed is user-specific. Authorization still runs before the cache lookup.

Two existing bugs in the same lines, fixed here:

• Feeds containing any event with a track or difficulty level returned a 500. e.categories << "..." pushed a plain String that to_ical can't serialize. It now uses append_categories.
• The feed was rendered with render inline:, which treats the string as an ERB template, so event text was evaluated. It now uses render plain: with text/calendar.

Query counts

Measured in spec/requests/ical_feeds_spec.rb with the test null cache, so these are uncached renders. Counts include the auth and session queries.

Endpoint	Before (2 → 10 events)	After (2 → 10 events)
/calendar.ics?full=1	28 → 60	23 → 23
/conferences/:id/schedule.ics	18 → 42	14 → 14

On a cache hit, /calendar.ics runs only the auth queries and three COUNT/MAX queries.

Output

I compared the before and after output on the same seeded data: short feed, full feed with a self-organized track, nil room, nil event type and unscheduled events, and two schedule.ics feeds. The only difference is line endings. They are now CRLF, as RFC 5545 requires. Before, they were LF because the ERB rendering converted them. For "before", I applied the append_categories fix, since the original code returned a 500.

Trade-offs

• DTSTAMP now records when the feed was cached, not when it was requested. That is allowed by the spec, and clients use UID and LAST-MODIFIED.
• The cache key misses data written without callbacks (update_column and the like). No app code does that for these models today. Entries expire after 12 hours regardless.
• The cached feed lives in whatever Rails.cache store production uses. If that is an in-process memory store, a few hundred KB of iCal text sits in RAM.
• /calendar.ics is admin-only today: Ability never grants :calendar to guests or regular users, so anonymous requests redirect to /. I left that alone. The new spec signs in as admin.

🤖 Generated with Claude Code

[cycomachead]

This branch now also contains #429, which rewrites the same SchedulesController#show. Merge #429 first; this PR's diff will then shrink back to the iCal changes.