1

I'm struggling with cache invalidation on Fastly and a rails app I work on. I'm using the fastly-rails gem and have confirmed the CNAMEs are set up correct. The issue is essentially as such:

A page is cached and served correctly from Fastly when there is no record of it in the cache. The resources surrogate keys are set using fastly-rails in a before action...

class SchoolsController < ApplicationController
  before_action :set_cache_control_headers, only: [:index, :show]

...

def show
  @school = School.find(params[:id])
  ...
  set_surrogate_key_header @school.record_key
end

from there, the page is cached and the next visit is served from Fastly servers. Now, in my active-admin controller action I have a call to invalidate the record in the cache after any updates are made as such:

ActiveAdmin.register School do
  
  ...

  def update
    super
    @school.purge
  end

end

this does ultimately end up invalidating the record on Fastly's end however, when I visit the URL /schools/:resource_slug I am still served the stale content from Fastly but if I visit /schools/:id I am served correctly from the application and then a second visit is served from the Fastly servers.

Any thoughts? Any one have a similar issue?

Community
  • 1
  • 1
Lowell Mower
  • 313
  • 4
  • 14
  • Can you share the code that makes use of the friendly_id? From the looks of it, this is only supporting finding by the id. – Hassan Shahid Jan 29 '16 at 00:24
  • Friendly ID supports finding a model which extends FreindlyId to find by id and will find the resource by slug name by default. – Lowell Mower Jan 29 '16 at 14:58
  • I'd suggest verifying that the `@school.record_key` value for both GET /schools/:id and /schools/:resource_slug is the same. – Hassan Shahid Jan 29 '16 at 23:27
  • I've resolved this and it ultimately had nothing to do with slugging nor friendly ID. Thank you for the suggestions. – Lowell Mower Jan 31 '16 at 00:11

0 Answers0