Latest stable GRDB 6.29.3 documentation displays a server error message

[groue]

Please describe the bug

The documentation of the latest stable version of GRDB v6.29.3 displays "An unknown error occurred."

Explain the steps needed to reproduce the bug

1. Navigate to https://swiftpackageindex.com/groue/grdb.swift/v6.29.3/
2. See the error message.

What was the expected behaviour?

A nice documentation page.

Screenshots

[finestructure]

Not sure what happened there but something must have been messed up in the Cloudflare cache. It's working now (and presumably would have corrected itself). Do you know if the docs for 6.29.3 worked in the past? I.e. do you know for how long the page was unavailable?

I'm asking because yesterday we deployed doc generation to default to Swift 6 and we have a situation here now where 6.29.3 was generated on Sep 7 with Swift 5.10 and the other two versions, master and v7.0.0-beta.2, were generated later, with Swift 6.

I don't think it should matter but it's the only change I can think of on our end that could have affected the 6.29.3 docs.

[groue]

Not sure what happened there but something must have been messed up in the Cloudflare cache. It's working now (and presumably would have corrected itself).

https://swiftpackageindex.com/groue/GRDB.swift/v6.29.3/documentation/grdb works on Chrome but is still broken on Safari.

On Safari: I paste https://swiftpackageindex.com/groue/GRDB.swift/v6.29.3/documentation/grdb and see an error message. The URL was automatically changed to https://swiftpackageindex.com/groue/grdb.swift/v6.29.3/. I hit Refresh in the browser, and now I see 404 - Not Found. (Maybe because a problem of case: GRDB vs. grdb in the URL)

Do you know if the docs for 6.29.3 worked in the past? I.e. do you know for how long the page was unavailable?

Yes, it has been working well since 6.29.3 has shipped on September 7. I sent links to users a couple of times since then.

We had an issue three days ago, #3407. After it was fixed, 6.29.3 was still online.

So the error started to happen somewhere after that.

I'm asking because yesterday we deployed doc generation to default to Swift 6 and we have a situation here now where 6.29.3 was generated on Sep 7 with Swift 5.10 and the other two versions, master and v7.0.0-beta.2, were generated later, with Swift 6.

Yes, the Package.swift has changed between of 6.29.3, and master = 7.0.0-beta2:

// swift-tools-version:5.7 <- GRDB 6.29.3
// swift-tools-version:6.0 <- GRDB 7.0.0-beta.2 and master

[daveverwer]

On Safari: I paste https://swiftpackageindex.com/groue/GRDB.swift/v6.29.3/documentation/grdb and see an error message. The URL was automatically changed to https://swiftpackageindex.com/groue/grdb.swift/v6.29.3/. I hit Refresh in the browser, and now I see 404 - Not Found. (Maybe because a problem of case: GRDB vs. grdb in the URL)

I suspect you are still seeing some cached files. I just tested with Safari now and do not see any of these issues. I did not get redirected from https://swiftpackageindex.com/groue/GRDB.swift/v6.29.3/documentation/grdb and do not see any errors.

[groue]

You must be right. On my phone it works now. 👍

[groue]

Thank you!

[groue]

I had to follow a six steps procedure:

• Search Google for the technique that invalidates the Safari cache
• Safari > Settings…
• Privacy
• Manage Website Data
• Search for swiftpackageindex
• Hit Clear

Maybe SPI stores something in the local storage? That's a weakness.

[daveverwer]

Maybe SPI stores something in the local storage? That's a weakness.

We do not. We only have one piece of code which accesses local storage and that's to show/hide a completely optional debug panel that we use for debugging and that people using the site would never need. It is referenced here:

SwiftPackageIndex-Server/FrontEnd/scripts/debug_panel.js

Line 20 in 66c690e

if (localStorage.getItem('spiDebug') === 'true') {

We do not store any cookies or other local storage.

I don't believe that DocC uses local storage, either. I can see no trace of it doing so in the web inspector but if it does then that's an issue for the DocC team rather than here.

Browsers love to hold on to their caches. I don't know why it's so hard to bypass them, but it is nothing we are doing.

[finestructure]

For me, ⌥⌘E in Safari has always sufficed to reset caches. I have the habit of hitting it multiple times, which I'm sure is a critical part of making it work 😬

[groue]

Thank you both for your support!