best-practices-badge icon indicating copy to clipboard operation
best-practices-badge copied to clipboard

API delivering outdated information.

Open jkowalleck opened this issue 1 year ago • 8 comments

Under certain circumstances (described here), https://www.bestpractices.dev/projects/7953/badge.json / https://bestpractices.coreinfrastructure.org/projects/7953/badge.json delivers outdated (cached?) information.

Expected response:

{"id":7953,"name":"CycloneDX PHP ComposerPlugin","updated_at":"2023-10-18T00:12:11.928Z","badge_level":"passing","tiered_percentage":125}

But for some client, the observed response always is:

{"id":7953,"name":"cyclonedx/cyclonedx-php-composer","updated_at":"2023-10-15T14:15:00.046Z","badge_level":"in_progress","tiered_percentage":24}

see https://github.com/badges/shields/issues/9660#issuecomment-1769187185 for more details and analysis.

jkowalleck avatar Oct 18 '23 20:10 jkowalleck

*Update: 2023-10-20

New issue: also the badge you provide yourself shows a 99% while it shows a "100%" in the top bar ossf_bp7953_2023-10-20_10-44-13

jkowalleck avatar Oct 20 '23 08:10 jkowalleck

probably related to our production caching

andrewfader avatar Nov 08 '23 04:11 andrewfader

This is very very strange. I thought we'd fixed this.

My best hypothesis is that this is a race condition in the communication between our site and our CDN (Fastly). We update our data and send a "remove from cache" message. However, if the CDN requests a data retrieval, executes a remove from cache, and then receives the data with old data, it would put old data into the cache. I don't see anything in the APIs that can fully prevent this, if that's what is going on.

If that's the problem, then maybe we need to re-send "remove from cache" messages later, to reduce the time where it can occur. That's basically harmless ("do no harm").

Other ideas welcome.

david-a-wheeler avatar Mar 13 '24 18:03 david-a-wheeler

We are having the same issue with the badge for the LLVM Project: https://www.bestpractices.dev/en/projects/8273

tstellar avatar Jun 13 '24 18:06 tstellar

That all should have been completely fixed by commit 9afb7fb06e298951e4d5b579d795930dcf4e5af (May 12 18:35:02 2024 -0400).

I thought that had fixed the last problems. I can't figure out what could be causing this now. Can you (re-)give me any specifics, ideally so I can reproduce, and a specific date/time with timezone?

david-a-wheeler avatar Jun 13 '24 20:06 david-a-wheeler

You can see the problem right now with the embedded link on github: https://github.com/llvm/llvm-project

tstellar avatar Jun 13 '24 22:06 tstellar

You can see the problem right now with the embedded link on github: https://github.com/llvm/llvm-project

github does an own caching of any external file/image to render. it does not display https://www.bestpractices.dev/projects/8273/badge, instead they display https://camo.githubusercontent.com/db77d49600af75fdcd7d87594c1d2e09377daf13f8687b9242cf7978c8003753/68747470733a2f2f7777772e626573747072616374696365732e6465762f70726f6a656374732f383237332f6261646765


Can you (re-)give me any specifics, ideally so I can reproduce, and a specific date/time with timezone?

current time: Thu Jun 13 23:30:34 2024 UTC

this is how it looks on the website: https://www.bestpractices.dev/en/projects/8273 image

jkowalleck avatar Jun 13 '24 23:06 jkowalleck

It seems like the image is flipping back and forth. It was showing the correct image on https://www.bestpractices.dev/en/projects/8273 a few days ago (but now it isn't). And the image here was briefly correct early today, but now it is showing 99% again.

tstellar avatar Jun 14 '24 06:06 tstellar