Old version being served

Questions / Help
1

Hello all :wave:

New user around here so still learning my way around.
I have a pretty vanilla Rails app where I’m experiencing an odd behaviour: if I request my page a dozen times, 3 or 4 times the server will respond back with an old version of the app.

I can see this by looking at the HTML (and seeing an old version of it that has since been changed and deployed) and also by noting that the CSS file being requested for instance has the wrong fingerprint (and therefore fails).

fly status

App
  Name     = <name>
  Owner    = personal
  Version  = 8
  Status   = deployed
  Hostname = <hostname>
  Platform = detached

Instances
ID      	PROCESS	VERSION	REGION	DESIRED	STATUS 	HEALTH CHECKS     	RESTARTS	CREATED
a0ac9992	app    	8      	mad   	run    	running	1 total, 1 passing	0       	9h7m ago

Initially I suspected some browser caching but have since discarded that (by disabling cache and trying different browsers), the “old” code is definitely coming from the server.

I’ve also tried looking through the dashboard and find cache items but no luck so far.

Am I missing something quite obvious? Has anyone seen something similar?

Thanks!

1 Like
2

Hi @heldermoreira

Thanks for sharing your status.

Are you using static caching on your fly.toml? Can you share it with us?

3

Hello @lubien :wave:

I don’t think so?

Here it is:

# fly.toml file generated for <app-name> on 2023-01-26T21:18:41Z

app = <app-name>
kill_signal = "SIGINT"
kill_timeout = 5
processes = []

[build]
  [build.args]
    BUILD_COMMAND = "bin/rails fly:build"
    SERVER_COMMAND = "bin/rails fly:server"

[deploy]
  release_command = "bin/rails fly:release"

[env]
  PORT = "8080"

[experimental]
  auto_rollback = true

[[services]]
  http_checks = []
  internal_port = 8080
  processes = ["app"]
  protocol = "tcp"
  script_checks = []
  [services.concurrency]
    hard_limit = 25
    soft_limit = 20
    type = "connections"

  [[services.ports]]
    force_https = true
    handlers = ["http"]
    port = 80

  [[services.ports]]
    handlers = ["tls", "http"]
    port = 443

  [[services.tcp_checks]]
    grace_period = "1s"
    interval = "15s"
    restart_limit = 0
    timeout = "2s"

[[statics]]
  guest_path = "/app/public"
  url_prefix = "/"
4

I can see the [[statics]] section there so maybe this is a caching problem?

Do you use any sort of cache invalidation method on rails such as having a digest inside the CSS URL on your HTML or are your stylesheets always under the same URL? Do you happen to know if the wrong styles come from certain fly regions? (You can verify response headers on your browser devtools).

5

I can see the [[statics]] section there so maybe this is a caching problem?

Good point. But to be fair I’m not sure what that section does.

Do you use any sort of cache invalidation method on rails such as having a digest inside the CSS URL on your HTML or are your stylesheets always under the same URL? Do you happen to know if the wrong styles come from certain fly regions? (You can verify response headers on your browser devtools).

A bit more detail on my near-vanilla setup. The only thing I added is tailwindcss-rails.
Ruby 3.0.2, Rails 7.0.5.

gem "importmap-rails"
gem "sprockets-rails"
gem "tailwindcss-rails"

The tailwind CSS file is compiled on precompile and is fingerprinted. Whenever I change the file’s contents it changes the fingerprint.

This being said, I think this is definitely something related to my fly setup or a problem on fly’s side.
Here’s the link of a fingerprinted CSS file on my application:

https://le-tour-rider-picker.fly.dev/assets/tailwind-afc767cedfae65e15f7c9bbe5a4723caa722e4cfb8b8196681144accb29721ef.css

If you request this file multiple times you see that it fails with a 404 sometimes and it succeeds with 200 in others. I checked my app (fly ssh console) and the file is definitely in the public/assets folder.

How can it be served sometimes and fail in others? :thinking:

6

I think this could be a problem on our side, your app seems to have an allocation (Fly v1) and a machine (Fly v2) running, I can see your app is on Platform = detached so that’s why I’m hinting at that. Can you experiment with running these commands?

# Remove nomad VMs. This won't affect your machines.
fly scale count 0 
# That ^ takes a few minutes to process on the backend after you've run it.

fly apps set-platform-version machines # you should be good after this!
8

Thank you @lubien, this did indeed fix my issue. I can consistently access the public folder now.

Could you elaborate just a little bit on what was the issue for my understanding going forward?
Was it because of the Fly v1 vs Fly v2 situation?

1 Like
9

At some point, your app was migrated from v1 to v2 (either on your end or automatically) but must have failed to finish it and stop the nomad VM (Fly v1) so our proxy understood that your app had two VMs running, one of them containing an old version of your app.

Fortunately, no migrations will be happening further on your app since you changed your platform version to machines already

10

Thank you for the explanation @lubien :handshake:

1 Like
11

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.