Repository navigation
Say that LiteFS is unsupported on every LiteFS guide - #2589
Merged
Merged
Conversation
about/support.mdx lists LiteFS under "Not Supported", and litefs/index.mdx carries a warning saying so, but the 20 other pages in litefs/ and the three framework guides walk a reader through setting it up with no such note. Adds a snippet with the support-scope half and imports it on those 23 pages. Does not touch litefs/index.mdx. Its inline warning also tells readers not to combine LiteFS with autostop/autostart, and that half is held back: it is a data-loss claim I could not trace past the September content import, so it wants confirming before it goes on more pages. Tracked in docs-tracking#365.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
Kaelyn confirmed where the warning came from: a support thread whose answer was not to use any replicated database with the autoscaler. That is enough provenance to repeat it. Adds it as a snippet on the eight pages where it means something, the ones that discuss running LiteFS on Fly. The other sixteen never mention fly.toml, Fly Machines or autostop, so a warning about the Fly Proxy's autoscaler would be noise there. litefs/index.mdx now uses both snippets instead of its inline Note, so the wording has one source. The support thread's broader point, that this applies to any replicated database and belongs on the autostop pages themselves, is left for its own issue.
Same claim, broken into a bold lead and three short sentences, and it now says permanent data loss rather than risking rollback and data loss.
This branch was successfully deployed
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Half of https://github.com/superfly/docs-tracking/issues/365.
about/support.mdxlists LiteFS under Not Supported, andlitefs/index.mdxcarries a warning saying so, but the 20 other pages inlitefs/and the three framework guides walk a reader through setting it up with no such note. Someone landing onlitefs/getting-started-flyfrom search never sees it.Adds
snippets/docs/litefs-unsupported.mdxwith the support-scope half, and imports it on 23 pages: the 20litefs/pages,rails/advanced-guides/litefs,laravel/advanced-guides/global-sqlite-litefsandblueprints/deno-kv-litefs. The four pages that already carry the LiteFS Cloud sunset snippet keep it and now show both, which is right: those document a retired service as well as LiteFS itself.Update, 21 Oct: the autostop warning is in too. @Lucais11 confirmed its provenance, a support thread whose answer was not to use any replicated database with the autoscaler. That is enough to repeat it, so it is now a second snippet on the eight pages where it means something: the ones that discuss running LiteFS on Fly. The other sixteen never mention
fly.toml, Fly Machines or autostop, so a warning about the Fly Proxy's autoscaler would be noise.litefs/index.mdxnow uses both snippets rather than its inline<Note>, so the wording has one source.Left for its own issue: the support thread's broader point, that this applies to any replicated database and belongs on
launch/autostop-autostartandreference/fly-proxy-autostop-autostart, neither of which mentions it today. Managed Postgres is out of scope there, since no MPG page offers autostop, autostart or scale-to-zero.Checked: all 23 pages have exactly one import and one tag, the four sunset pages still have theirs, and the
/about/support#scope-of-supportanchor resolves.On the Vale annotations. This PR shows none, and the reason is now known: the workflow told
vale-actionthe changed-file list was comma-separated whentj-actions/changed-filesemits it space-separated, so Vale got one argument holding every path and returned an empty result. Fixed in #2590, tracked in https://github.com/superfly/docs-tracking/issues/375.An earlier version of this note said #2544 "did not achieve what I claimed". That was wrong. The glob fix in #2544 was correct; this separator bug predates the migration and was hiding it. Once #2590 lands, a PR like this one will annotate the pre-existing prose findings in the files it touches.
Checked: all 23 pages have exactly one import and one tag, the four sunset pages still have theirs, and the
/about/support#scope-of-supportanchor resolves.Correction on the Vale annotations. I wrote that this PR would show 8. It shows none. Vale in CI returned an empty result for all 24 files, while the identical command, Vale version, commit and post-sync styles produce 8 findings locally, so something in the CI environment is suppressing them and I have not identified what. The two annotations on this PR are GitHub Actions infrastructure warnings about Node 20 and
ubuntu-latest, not Vale.That means #2544 did not achieve what I claimed for it: prose linting still reports nothing on pull requests, for a different reason than before. Needs its own investigation, starting with
debug: trueon the action to see how Vale resolves its config in CI.