fix(docs): remove broken /docs/databases redirect to nonexistent path #37316
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The .htaccess file had a catch-all redirect that sent all /docs/databases* URLs to /docs/configuration/databases, which no longer exists since databases documentation moved to /docs/databases/. This caused a confusing behavior where clicking a link to /docs/databases worked (client-side navigation), but refreshing the page or directly visiting the URL would 301 redirect to a 404. Changes: - Remove the catch-all `docs/databases.*` rewrite rule - Update druid.html redirect to point to /docs/databases - Update yugabyte redirect to point to /docs/databases - Fix broken links in quickstart, faq, kubernetes, and timezones docs Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Contributor
|
CodeAnt AI is reviewing your PR. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
Contributor
Sequence DiagramThis PR removes a catch‑all .htaccess redirect and updates redirects/links so that requesting /docs/databases loads the databases overview page directly instead of 301‑redirecting to a nonexistent path. The diagram shows the simplified successful request flow after the fix. sequenceDiagram
participant Browser
participant WebServer as "WebServer (.htaccess)"
participant DocsSite as "Docs (static site)"
Browser->>WebServer: GET /docs/databases
WebServer->>DocsSite: Request /docs/databases (no redirect)
DocsSite-->>WebServer: 200 OK (databases overview page)
WebServer-->>Browser: 200 OK (renders /docs/databases)
Generated by CodeAnt AI |
Contributor
|
CodeAnt AI finished reviewing your PR. |
✅ Deploy Preview for superset-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
![bito-code-review[bot]](https://avatars.githubusercontent.com/in/1061978?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review Agent Run #ebd211
Actionable Suggestions - 1
-
docs/docs/configuration/timezones.mdx - 1
- Broken documentation link · Line 23-23
Additional Suggestions - 2
-
docs/docs/configuration/timezones.mdx - 2
-
Spelling error in docs · Line 23-23The word 'serializd' appears to be a typo for 'serialized' in the description of timestamp handling.
Code suggestion
@@ -23,1 +23,1 @@ -The challenge however lies with the slew of [database engines](/docs/databases#installing-drivers-in-docker) which Apache Superset supports and various inconsistencies between their [Python Database API (DB-API)](https://www.python.org/dev/peps/pep-0249/) implementations combined with the fact that we use [Pandas](https://pandas.pydata.org/) to read SQL into a DataFrame prior to serializing to JSON. Regrettably Pandas ignores the DB-API [type_code](https://www.python.org/dev/peps/pep-0249/#type-objects) relying by default on the underlying Python type returned by the DB-API. Currently only a subset of the supported database engines work correctly with Pandas, i.e., ensuring timestamps without an explicit timestamp are serializd to JSON with the server timezone, thus guaranteeing the client will display timestamps in a consistent manner irrespective of the client's timezone. +The challenge however lies with the slew of [database engines](/docs/databases#installing-drivers-in-docker) which Apache Superset supports and various inconsistencies between their [Python Database API (DB-API)](https://www.python.org/dev/peps/pep-0249/) implementations combined with the fact that we use [Pandas](https://pandas.pydata.org/) to read SQL into a DataFrame prior to serializing to JSON. Regrettably Pandas ignores the DB-API [type_code](https://www.python.org/dev/peps/pep-0249/#type-objects) relying by default on the underlying Python type returned by the DB-API. Currently only a subset of the supported database engines work correctly with Pandas, i.e., ensuring timestamps without an explicit timestamp are serialized to JSON with the server timezone, thus guaranteeing the client will display timestamps in a consistent manner irrespective of the client's timezone.
-
Unclear phrasing in docs · Line 23-23The phrase 'timestamps without an explicit timestamp' is redundant and unclear; it likely means 'timestamps without an explicit timezone'.
Code suggestion
@@ -23,1 +23,1 @@ - The challenge however lies with the slew of [database engines](/docs/databases#installing-drivers-in-docker) which Apache Superset supports and various inconsistencies between their [Python Database API (DB-API)](https://www.python.org/dev/peps/pep-0249/) implementations combined with the fact that we use [Pandas](https://pandas.pydata.org/) to read SQL into a DataFrame prior to serializing to JSON. Regrettably Pandas ignores the DB-API [type_code](https://www.python.org/dev/peps/pep-0249/#type-objects) relying by default on the underlying Python type returned by the DB-API. Currently only a subset of the supported database engines work correctly with Pandas, i.e., ensuring timestamps without an explicit timestamp are serialized to JSON with the server timezone, thus guaranteeing the client will display timestamps in a consistent manner irrespective of the client's timezone. + The challenge however lies with the slew of [database engines](/docs/databases#installing-drivers-in-docker) which Apache Superset supports and various inconsistencies between their [Python Database API (DB-API)](https://www.python.org/dev/peps/pep-0249/) implementations combined with the fact that we use [Pandas](https://pandas.pydata.org/) to read SQL into a DataFrame prior to serializing to JSON. Regrettably Pandas ignores the DB-API [type_code](https://www.python.org/dev/peps/pep-0249/#type-objects) relying by default on the underlying Python type returned by the DB-API. Currently only a subset of the supported database engines work correctly with Pandas, i.e., ensuring timestamps without an explicit timezone are serialized to JSON with the server timezone, thus guaranteeing the client will display timestamps in a consistent manner irrespective of the client's timezone.
-
Review Details
-
Files reviewed - 5 · Commit Range:
6ef2cfe..6ef2cfe- docs/docs/configuration/timezones.mdx
- docs/docs/faq.mdx
- docs/docs/installation/kubernetes.mdx
- docs/docs/quickstart.mdx
- docs/static/.htaccess
-
Files skipped - 0
-
Tools
- Whispers (Secret Scanner) - ✔︎ Successful
- Detect-secrets (Secret Scanner) - ✔︎ Successful
Bito Usage Guide
Commands
Type the following command in the pull request comment and save the comment.
-
/review- Manually triggers a full AI review. -
/pause- Pauses automatic reviews on this pull request. -
/resume- Resumes automatic reviews. -
/resolve- Marks all Bito-posted review comments as resolved. -
/abort- Cancels all in-progress reviews.
Refer to the documentation for additional commands.
Configuration
This repository uses Superset You can customize the agent settings here or contact your Bito workspace admin at evan@preset.io.
Documentation & Help
AI Code Review powered by
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
SUMMARY
Fixes a redirect loop causing 404 errors when accessing
/docs/databases/directly.The Problem: The
.htaccessfile had a catch-all rewrite rule that redirected all/docs/databases*URLs to/docs/configuration/databases. However, since the databases documentation was moved to/docs/databases/, this old target path no longer exists.This caused confusing behavior:
/docs/databasesfrom within the site worked (client-side navigation)/docs/configuration/databases→ 404The Fix:
docs/databases.*rewrite rule from.htaccessdruid.htmlredirect to point to/docs/databasesinstead of/docs/configuration/databasesdocs/databases/yugabyte/redirect to point to/docs/databasesBEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Before:
/docs/databases→ 301 redirect →/docs/configuration/databases→ 404After:
/docs/databases→ 200 OK (loads database overview page)TESTING INSTRUCTIONS
cd docs && npm run build && npm run servehttp://localhost:3000/docs/databasesdirectly in browserADDITIONAL INFORMATION
🤖 Generated with Claude Code