Redirect running despite shadowed file existing in deploying

Hi @devotox, I’ve made a change to how your site’s redirects work. Can you check if your redirect rules work now?

Was this made in the settings somewhere that I can see or in the netlify.toml? I ask because now that I have been able to look at this my site as automatically deployed at least 3 times (wooo robots ay)

At the moment with the latest deploy I still have the same problem but like I said many deploys have happened since your message

Can you tell me which urls are still getting redirected? Since your build seems to change all your filenames, I recommend also taking a look at the post about making the most of our CDN cache

Anything in the /assets/ directory

Filenames are changed depending on md5 hashes. This will slow down when development slows down

Hi, we have an experimental fix for the issue that you describe and have enabled it for your site. Could you re-deploy your site and see if that helps?

Also, I just wanted to point out that you have a redirect rule conflict here:

[[redirects]]
  status = 200
  force = false
  from = "/*"
  to = "/.netlify/functions/fastboot/:splat"

[[redirects]]
  status = 200
  force = false
  from = "/*"
  to = "/index.html"

Basically, that second rule will never get used.

Thank you. Deploying now to test.

Yes i know the second will never run and that is intentional. I have them both still in there because i was commenting out the functions redirect every time i needed the site to actually work

Please let us know how the testing goes, @devotox. We’re happy to answer if there are other questions as well.

I am still getting a 502 on requests that should hit the filesystem after my latest deploy.

6:20:18 PM: {"level":"info","time":1582914018317,"pid":8,"hostname":"169.254.172.189","reqId":4,"req":{"method":"GET","url":"/engines-dist/home/assets/engine.js"},"v":1,"message":"incoming request","environment":"production","label":"zenunu","timestamp":"2020-02-28T18:20:18.317Z"}

Hi, @devotox, that IP address isn’t routable (it is a local-link address) and therefore I cannot search our logs for it.

We still need the x-nf-request-id or the information it replaces to trace the requests returning the 502s. Would you please send us that information?

@luke

{
    "level": "info",
    "time": 1583163637524,
    "pid": 7,
    "hostname": "169.254.56.253",
    "message": "Fastboot Visit",
    "hashedKey": "82e8be118c5db25d4d824978014156ca7cbf8b05",
    "cacheHit": false,
    "request": {
        "url": "/assets/images/icons/icon-16-3cf27b93565c6c1e5359b2ea256f0416.png",
        "host": "zenunu.netlify.com",
        "port": 80,
        "path": "/assets/images/icons/icon-16-3cf27b93565c6c1e5359b2ea256f0416.png",
        "method": "GET",
        "protocol": "https",
        "location": "https://zenunu.netlify.com/assets/images/icons/icon-16-3cf27b93565c6c1e5359b2ea256f0416.png",
        "headers": {
            "accept": "image/webp,image/apng,image/*,*/*;q=0.8",
            "accept-encoding": "br, gzip",
            "accept-language": "en-GB,en-US;q=0.9,en;q=0.8",
            "client-ip": "86.53.244.42",
            "cookie": "ember_simple_auth-session=%7B%22authenticated%22%3A%7B%7D%7D; ember_simple_auth-session-expiration_time=86400",
            "referer": "https://zenunu.netlify.com/",
            "sec-fetch-mode": "no-cors",
            "sec-fetch-site": "same-origin",
            "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36",
            "via": "https/2 Netlify[b5fe4bec-7a3d-48f7-af89-114c527bb1a1] (ApacheTrafficServer/7.1.9)",
            "x-bb-ab": "0.246849",
            "x-bb-client-request-uuid": "b5fe4bec-7a3d-48f7-af89-114c527bb1a1-3663412",
            "x-bb-ip": "86.53.244.42",
            "x-bb-loop": "1",
            "x-country": "GB",
            "x-forwarded-for": "86.53.244.42",
            "x-forwarded-proto": "https",
            "x-language": "en,en,en;q=0.8",
            "x-nf-client-connection-ip": "86.53.244.42",
            "x-apigateway-event": "%7B%22path%22%3A%22%2Fassets%2Fimages%2Ficons%2Ficon-16-3cf27b93565c6c1e5359b2ea256f0416.png%22%2C%22httpMethod%22%3A%22GET%22%2C%22headers%22%3A%7B%22accept%22%3A%22image%2Fwebp%2Cimage%2Fapng%2Cimage%2F*%2C*%2F*%3Bq%3D0.8%22%2C%22accept-encoding%22%3A%22br%2C%20gzip%22%2C%22accept-language%22%3A%22en-GB%2Cen-US%3Bq%3D0.9%2Cen%3Bq%3D0.8%22%2C%22client-ip%22%3A%2286.53.244.42%22%2C%22cookie%22%3A%22ember_simple_auth-session%3D%257B%2522authenticated%2522%253A%257B%257D%257D%3B%20ember_simple_auth-session-expiration_time%3D86400%22%2C%22referer%22%3A%22https%3A%2F%2Fzenunu.netlify.com%2F%22%2C%22sec-fetch-mode%22%3A%22no-cors%22%2C%22sec-fetch-site%22%3A%22same-origin%22%2C%22user-agent%22%3A%22Mozilla%2F5.0%20(Macintosh%3B%20Intel%20Mac%20OS%20X%2010_15_0)%20AppleWebKit%2F537.36%20(KHTML%2C%20like%20Gecko)%20Chrome%2F79.0.3945.130%20Safari%2F537.36%22%2C%22via%22%3A%22https%2F2%20Netlify%5Bb5fe4bec-7a3d-48f7-af89-114c527bb1a1%5D%20(ApacheTrafficServer%2F7.1.9)%22%2C%22x-bb-ab%22%3A%220.246849%22%2C%22x-bb-client-request-uuid%22%3A%22b5fe4bec-7a3d-48f7-af89-114c527bb1a1-3663412%22%2C%22x-bb-ip%22%3A%2286.53.244.42%22%2C%22x-bb-loop%22%3A%221%22%2C%22x-country%22%3A%22GB%22%2C%22x-forwarded-for%22%3A%2286.53.244.42%22%2C%22x-forwarded-proto%22%3A%22https%22%2C%22x-language%22%3A%22en%2Cen%2Cen%3Bq%3D0.8%22%2C%22x-nf-client-connection-ip%22%3A%2286.53.244.42%22%7D%2C%22queryStringParameters%22%3A%7B%7D%2C%22isBase64Encoded%22%3Atrue%7D",
            "x-apigateway-context": "%7B%22callbackWaitsForEmptyEventLoop%22%3Afalse%2C%22functionVersion%22%3A%22%24LATEST%22%2C%22functionName%22%3A%228ab29a7c639d7e8e0eeecaf0a2b6d86cb758fd5d01f3df2444eb4ab2b031aef1%22%2C%22memoryLimitInMB%22%3A%221024%22%2C%22logGroupName%22%3A%22%2Faws%2Flambda%2F8ab29a7c639d7e8e0eeecaf0a2b6d86cb758fd5d01f3df2444eb4ab2b031aef1%22%2C%22logStreamName%22%3A%222020%2F03%2F02%2F%5B%24LATEST%5D483b81943be84320b7c025354f81d466%22%2C%22clientContext%22%3A%7B%22custom%22%3A%7B%22netlify%22%3A%22eyJzaXRlX3VybCI6Imh0dHBzOi8vemVudW51Lm5ldGxpZnkuY29tIn0%3D%22%7D%7D%2C%22invokedFunctionArn%22%3A%22arn%3Aaws%3Alambda%3Aus-east-1%3A673769985865%3Afunction%3A8ab29a7c639d7e8e0eeecaf0a2b6d86cb758fd5d01f3df2444eb4ab2b031aef1%22%2C%22awsRequestId%22%3A%221058669a-c566-4e35-b322-93a669ebb8e6%22%7D",
            "host": "zenunu.netlify.com",
            "content-length": "0",
            "x-forwarded-host": "zenunu.netlify.com",
            "location": "https://zenunu.netlify.com/assets/images/icons/icon-16-3cf27b93565c6c1e5359b2ea256f0416.png"
        }
    },
    "response": {
        "_headers": {}
    },
    "v": 1,
    "environment": "production",
    "label": "zenunu",
    "timestamp": "2020-03-02T15:40:37.524Z"
}

@luke

x-nf-request-id: dfe167ba-dfd9-4edb-81c3-557b6da929e4-9928409

Hi, @devotox. Thank you for sending those two examples.

For both the x-nf-request-ids (dfe167ba-dfd9-4edb-81c3-557b6da929e4-9928409 and b5fe4bec-7a3d-48f7-af89-114c527bb1a1-3663412), I can confirm that the file in question exists in that deploy but that the HTTP request is being proxied to the function instead.

This is incorrect behavior as the rule is not a force or 200! (with the !) so the URL should send the file in the deploy and not proxy the HTTP request.

We do have an open issue tracking this. I’m also researching a possible workaround in the meantime.

We’ll update this community topic again as soon as I know more about the workaround and if/when the issue itself is known to be resolved.

@luke Thank you guys for being on top of this and your quick replies. could you point me to the internal ticket to also watch that

Just got Luke’s proposed fix in place (a feature flag we applied to the zenunu site). Could you trigger one more deploy to apply that configuration, and let us know if it works better or no?

@luke @fool I deployed twice and tested in an incognito window. You will see from the request ID below that we still hit the serverless function when requesting an image on disk.

x-nf-request-id: 4c421348-8893-4880-ab87-69a48137c368-2592124

Hi, @devotox, I did confirm that the HTTP request for the asset associated with the most recent x-nf-request-id header (4c421348-8893-4880-ab87-69a48137c368-2592124) was proxied in error. This occurred even with the workaround in place (which is the behavior the open issue covers).

The open issue is on a private Git repository so there is no public URL to share. However, that issue and this community topic are now cross-linked for tracking. If/when the issue is known to be resolved, we’ll follow-up here to let you know about it.

@luke Can you give me some context into what the bug was and what workaround was attempted. Maybe I can think of something being able to think of it from a fresh place.

Hi @devotox - we can’t share more details at present, but, I can see that the issue was triaged and will be worked on when we have some availability. We’ll update this thread when there is news to share!