Build value is out of sync

[tpoisot]

I am struggling to see what the purpose of giving the build every time is - especially because if I know where some resource is for a former build, I cannot get access to it if the build has changed. As a result, there's code I am maintaining that breaks often when the build changes.

@keesey - can you share more about the use-case or philosophy here? I'm trying to make sense of whether always pretending the build doesn't exist and following the redirect makes more sense (but then I can't use page)

[tpoisot]

I think I just identified the cause of the bugs I'm encountering. The build field isn't always properly updated. Right now, there was a brief moment where the root of the API said 423, but the rest of the endpoints were expecting 425.

[tpoisot]

Additional bit of information: I can still access an outdated build

and sometimes, accessing the API root is not leading me to the correct build number - is this an issue with the build number being cached somewhere and users getting served the wrong value?

[keesey]

This is an issue with me running two builds today.

The use case for always including the build is so that the CDN can handle more traffic without going through to the origin, and so that the consumer will know if any previously loaded data is now out of date. Any error response should have the latest build number in it so that you can retry.

If you’re still getting an old build number from the root, that could be a bug.

[keesey]

And if you can still access old builds I might need to check if the CDN purge is working properly.

[tpoisot]

And if you can still access old builds I might need to check if the CDN purge is working properly.

I just checked, I can currently access all builds from 421 to 425. In some cases, the root of the API gives build 423, 424, or 425 as well.

[keesey]

I just did a manual CloudFront purge to fix the problem temporarily. I'll look into a longer-term solution.