docs(changelog): Sign in with ClickHouse Cloud#2948
Conversation
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
dosubot
Bot
added
the
size:S
|
@claude review |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| title: Sign in with ClickHouse Cloud | ||
| description: Use your ClickHouse Cloud account to sign in to Langfuse Cloud, and link it to an existing Langfuse account. | ||
| author: Steffen | ||
| ogImage: /images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png |
There was a problem hiding this comment.
The file public/images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png is referenced in ogImage (line 6) and in the <Frame> block (line 20) but does not exist in the repository. The published page will render a broken image, and the OG image used for social/link previews will fail to load. The PR test plan marks this item as unchecked — the screenshot must be added before merging.
Prompt To Fix With AI
This is a comment left during a code review.
Path: content/changelog/2026-05-14-sign-in-with-clickhouse-cloud.mdx
Line: 6
Comment:
**Missing image asset blocks publish**
The file `public/images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png` is referenced in `ogImage` (line 6) and in the `<Frame>` block (line 20) but does not exist in the repository. The published page will render a broken image, and the OG image used for social/link previews will fail to load. The PR test plan marks this item as unchecked — the screenshot must be added before merging.
How can I resolve this? If you propose a fix, please make it concise.|
|
||
| <ChangelogHeader /> | ||
|
|
||
| You can now sign in to Langfuse Cloud with your ClickHouse Cloud account. The new provider sits alongside Google, GitHub, Microsoft, and email/password on the login screen and is available across all Langfuse Cloud regions (US, EU, and HIPAA). |
There was a problem hiding this comment.
The Langfuse Cloud Japan region (launched 2026-04-27) is documented as having full platform parity with Cloud EU and Cloud US. The text says the provider is "available across all Langfuse Cloud regions (US, EU, and HIPAA)" but does not mention Japan. If ClickHouse Cloud sign-in is also enabled on the Japan region, the region list should be updated; if it is intentionally excluded, a brief note explaining why would prevent confusion for Japan-region users. Is ClickHouse Cloud sign-in available on the Japan region as well? If so, should it be added to the list?
Prompt To Fix With AI
This is a comment left during a code review.
Path: content/changelog/2026-05-14-sign-in-with-clickhouse-cloud.mdx
Line: 13
Comment:
**Japan region may be omitted**
The Langfuse Cloud Japan region (launched 2026-04-27) is documented as having full platform parity with Cloud EU and Cloud US. The text says the provider is "available across all Langfuse Cloud regions (US, EU, and HIPAA)" but does not mention Japan. If ClickHouse Cloud sign-in is also enabled on the Japan region, the region list should be updated; if it is intentionally excluded, a brief note explaining why would prevent confusion for Japan-region users. Is ClickHouse Cloud sign-in available on the Japan region as well? If so, should it be added to the list?
How can I resolve this? If you propose a fix, please make it concise.![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
|
|
||
| <ChangelogHeader /> | ||
|
|
||
| You can now sign in to Langfuse Cloud with your ClickHouse Cloud account. The new provider sits alongside Google, GitHub, Microsoft, and email/password on the login screen and is available across all Langfuse Cloud regions (US, EU, and HIPAA). |
There was a problem hiding this comment.
🔴 The line "available across all Langfuse Cloud regions (US, EU, and HIPAA)" is internally contradictory — Langfuse Cloud also has a Japan region (jp.cloud.langfuse.com, see content/security/data-regions.mdx and the 2026-04-27 changelog entry), so the parenthetical does not match "all". Either add Japan to the list (if ClickHouse SSO is supported there) or change "all Langfuse Cloud regions" to "the US, EU, and HIPAA regions" (if Japan is intentionally excluded). The PR's own test plan flags this exact uncertainty.
Extended reasoning...
What's wrong
Line 13 of content/changelog/2026-05-14-sign-in-with-clickhouse-cloud.mdx says:
available across all Langfuse Cloud regions (US, EU, and HIPAA)
The parenthetical lists three regions but uses the word "all", which is factually inaccurate. Langfuse Cloud has four regions, not three.
Proof — step by step
- Open
content/security/data-regions.mdx— it enumerates the supported Langfuse Cloud regions and includes Japan (jp.cloud.langfuse.com, Tokyoap-northeast-1) alongside US, EU, and HIPAA. content/changelog/2026-04-27-langfuse-cloud-japan.mdxis the public announcement that the Japan region went live on 2026-04-27 — i.e. it was live for ~2.5 weeks before this PR was opened on 2026-05-14.- Other security docs (
content/security/dpa.mdx,content/security/subprocessors.mdx,content/security/hipaa.mdx) consistently treat EU / US / Japan / HIPAA as the four regions. - Therefore the statement "available across all Langfuse Cloud regions (US, EU, and HIPAA)" is self-contradictory: the universal quantifier "all" is followed by a list that drops one of the four regions.
Why this matters
This is a public-facing changelog post that customers will read to decide whether they can adopt the new SSO provider. The ambiguity has real consequences in either direction:
- If ClickHouse Cloud sign-in is enabled in Japan, customers in the Japan region may incorrectly conclude it isn't available to them and not try it.
- If it is not enabled in Japan, the word "all" misleads Japan customers into thinking they can use it, leading to a broken login attempt and a support request.
Confirmed by the PR author's own test plan
The PR description includes the line:
Confirm the list of supported regions in the post (US/EU/HIPAA — adjust if Japan or others apply)
— so the author already knows this is unverified and explicitly asked for it to be checked before merge.
How to fix
Pick one of the following, depending on whether the new SSO provider is actually enabled in the Japan region:
- If supported in Japan:
...available across all Langfuse Cloud regions (US, EU, Japan, and HIPAA). - If not supported in Japan:
...available in the US, EU, and HIPAA regions on Langfuse Cloud.(drop "all")
|  | ||
| </Frame> | ||
|
|
||
| See [Authentication & SSO](/docs/administration/authentication-and-sso) for the full list of supported providers. |
There was a problem hiding this comment.
🔴 The closing sentence links readers to Authentication & SSO "for the full list of supported providers", but that page does not list ClickHouse Cloud anywhere — its Social Logins section (content/docs/administration/authentication-and-sso.mdx lines 31-38) still only lists Google, GitHub, and Azure AD (Entra ID), and the intro on line 9 explicitly says "social logins (Sign in with Google, GitHub, Microsoft)". Update authentication-and-sso.mdx as part of this rollout (add ClickHouse Cloud to the Social Logins bullet list and to the line-9 intro) so the changelog and the canonical doc agree at the moment of the public announcement.
Extended reasoning...
What the bug is
The changelog announces a new social login provider (ClickHouse Cloud) and closes with: "See Authentication & SSO for the full list of supported providers." That link points to content/docs/administration/authentication-and-sso.mdx, which is the canonical reference page for sign-in methods. However, that page has not been updated as part of this PR and does not mention ClickHouse Cloud anywhere.
Code path that triggers it
A reader sees the announcement on the /changelog route, follows the closing link expecting to confirm the new provider is supported, and lands on /docs/administration/authentication-and-sso. Two places on that page contradict the changelog:
- Line 9 (intro): "By default, Langfuse supports email/password and social logins (Sign in with Google, GitHub, Microsoft)."
- Lines 31-38 (Social Logins section):
## Social Logins For simplified access, users can sign in using their existing social accounts: - Google - GitHub - Azure AD (Entra ID)
Neither mentions ClickHouse Cloud.
Why existing code doesn't prevent it
This is a cross-file documentation consistency issue — there is no automated check that the providers listed in the changelog match those in the authoritative SSO doc, so the two can drift, and they have drifted here. The PR adds the changelog file only and does not touch authentication-and-sso.mdx.
Impact
This is a user-visible inconsistency at the exact moment of the public announcement. Anyone who clicks the link the changelog explicitly invites them to click — to verify or learn more about the new provider — will see a list that contradicts the announcement. That undermines trust in the docs and the rollout, and is the kind of thing the changelog's closing line is specifically designed to avoid.
How to fix it
In content/docs/administration/authentication-and-sso.mdx, update both the intro line and the Social Logins list to include ClickHouse Cloud, e.g.:
- Line 9:
... social logins (Sign in with Google, GitHub, Microsoft, ClickHouse Cloud). - Lines 35-37 bullet list: add
- ClickHouse Cloud(with the appropriate availability note if it is Cloud-only).
If ClickHouse Cloud is only available on Langfuse Cloud (as the changelog implies: "available across all Langfuse Cloud regions"), the doc should also call that out so self-hosted readers are not misled.
Step-by-step proof
- Open the new changelog (
content/changelog/2026-05-14-sign-in-with-clickhouse-cloud.mdx, line 23): the page ends withSee [Authentication & SSO](/docs/administration/authentication-and-sso) for the full list of supported providers. - Follow that link to
content/docs/administration/authentication-and-sso.mdx. - Read line 9 — it lists Google, GitHub, Microsoft.
- Read lines 31-38 — the
## Social Loginssection lists exactly three providers: Google, GitHub, Azure AD (Entra ID). - Search the whole file for
ClickHouse— zero matches. - The reader has now followed the changelog's own pointer to "the full list of supported providers" and the newly-announced provider is not on that list. Bug confirmed.
| <Frame fullWidth> | ||
|  | ||
| </Frame> |
There was a problem hiding this comment.
🔴 The frontmatter sets ogImage to /images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png, and the inline <Frame> on lines 19-21 embeds the same path. Since ChangelogHeader automatically renders ogImage at the top of the post (unless showOgInHeader: false is set), the identical screenshot will appear twice on the published page. Fix by dropping the inline <Frame>, swapping it for a different screenshot, or adding showOgInHeader: false to the frontmatter.
Extended reasoning...
What the bug is
The new changelog MDX file declares ogImage: /images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png in its frontmatter (line 6) and also embeds an inline <Frame> containing the same image path on lines 19-21:
<Frame fullWidth>
</Frame>Why the existing component code doesn't prevent this
components/changelog/ChangelogHeader.tsx lines 69-83 unconditionally renders the ogImage (or ogVideo/gif if provided) as an <Image> element at the top of every changelog post, unless the frontmatter explicitly sets showOgInHeader: false:
{showOgInHeader === false ? null : ogVideo ? (
<Video src={ogVideo} gifStyle />
) : ogImage ? (
<Image src={(gif ?? ogImage) as string} ... />
) : null}The new MDX does not set showOgInHeader, so the default branch fires and the header renders the screenshot.
Step-by-step proof
<ChangelogHeader />mounts and readsfrontMatterviauseChangelogFrontMatter().frontMatter.showOgInHeaderisundefined(not set in this MDX), soshowOgInHeader === falseisfalse→ the conditional falls through.frontMatter.ogVideoisundefined→ falls through to theogImagebranch.frontMatter.ogImageis/images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png→ renders<Image src="/images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png" ... />at the top of the post.- MDX body then renders the inline
<Frame>containing the same/images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.pngpath. - Result: two
<img>tags pointing to the same asset on the same page.
Convention in the repo
Other recent changelogs that use ogImage (2026-04-13-experiments-rebuild.mdx, 2026-04-13-amazon-bedrock-api-keys.mdx, 2026-04-27-langfuse-cloud-japan.mdx, 2026-05-08-self-service-enterprise-sso-setup.mdx) do not also inline the same image. The one entry that uses both an ogImage and a body <Frame> (2026-02-13-observation-level-evals.mdx) deliberately uses two different files. So the established convention is to avoid duplicating the same asset.
Impact and fix
Once the screenshot is added at public/images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png (the PR checklist requires this before merge), readers on /changelog/2026-05-14-sign-in-with-clickhouse-cloud will see the identical screenshot rendered twice. Fix is a one-liner — pick any of: (a) delete the inline <Frame> block on lines 19-21, (b) replace the inline image with a different screenshot, or (c) add showOgInHeader: false to the frontmatter to suppress the header image.
| author: Steffen | ||
| ogImage: /images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png | ||
| --- | ||
|
|
||
| import { ChangelogHeader } from "@/components/changelog/ChangelogHeader"; | ||
|
|
||
| <ChangelogHeader /> | ||
|
|
||
| You can now sign in to Langfuse Cloud with your ClickHouse Cloud account. The new provider sits alongside Google, GitHub, Microsoft, and email/password on the login screen and is available across all Langfuse Cloud regions (US, EU, and HIPAA). | ||
|
|
||
| This is convenient for teams who already manage access through ClickHouse Cloud and want one identity for both products — for example, when onboarding a new engineer who already has a ClickHouse Cloud seat, switching from password-based login to SSO without creating a second account, or keeping access reviews scoped to a single provider. | ||
|
|
||
| If you already have a Langfuse account that uses another sign-in method, signing in with ClickHouse Cloud once using the same email links the two — your projects, memberships, and API keys carry over. | ||
|
|
||
| <Frame fullWidth> | ||
|  | ||
| </Frame> |
There was a problem hiding this comment.
🔴 The MDX references /images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png in both the ogImage frontmatter (line 6) and the inline <Frame> (line 20), but the image file is not committed in this PR. If merged as-is, the changelog page will render a broken image and the OpenGraph preview will 404 when the URL is shared. The PR's own test plan flags this as an unchecked TODO — please commit public/images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png alongside this MDX before merging.
Extended reasoning...
What the bug is
The new changelog entry content/changelog/2026-05-14-sign-in-with-clickhouse-cloud.mdx references an image at /images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png in two distinct places:
- Frontmatter
ogImage(line 6):ogImage: /images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png— used to generate the OpenGraph preview card when the page is shared on social media / chat. - Inline
<Frame>(line 20):— the screenshot embedded in the body of the changelog post.
However, the PR does not add a corresponding asset to public/images/changelog/. The directory only contains older images (e.g., 2026-05-05-experiment-ci-cd.png), with no 2026-05-14-sign-in-with-clickhouse-cloud.png.
Why existing code doesn't prevent it
There is no build-time validation that ogImage paths or inline image references in MDX resolve to committed assets in public/. Both Next.js' /public static serving and the MDX image component silently 404 at request time rather than failing the build, so this won't be caught by pnpm build or any of the docs lint/typecheck steps.
Impact
Once this PR merges to main and deploys:
- The body of
/changelog/2026-05-14-sign-in-with-clickhouse-cloudwill render a broken image (alt text only). - Any social/chat unfurl of the changelog URL will request a non-existent OpenGraph image — the unfurl will either show no preview or a 404 placeholder.
- Both regressions are user-visible on a public marketing surface.
Step-by-step proof
- Clone the PR branch.
ls public/images/changelog/ | grep clickhouse→ no matching file (verified by multiple reviewers; only2026-05-05-experiment-ci-cd.pngis present for May 2026).pnpm devand visit/changelog/2026-05-14-sign-in-with-clickhouse-cloud→ the inline<Frame>renders a broken<img>(the browser shows the alt text and a missing-image icon, and DevTools shows a 404 for/images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png).curl -I http://localhost:3000/images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png→HTTP/1.1 404 Not Found.- Inspect the generated
<head>of the changelog page — the OpenGraphog:imagemeta tag points to the same 404 URL.
How to fix
Commit the actual screenshot at public/images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png as part of this PR. The PR's own test plan already lists this as an unchecked TODO ("Add login screen screenshot at public/images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png (used as both inline image and ogImage)"), so the author is aware — it just needs to be done before merge.
1 participant
Summary
Test plan
public/images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png(used as both inline image and ogImage)🤖 Generated with Claude Code
Greptile Summary
This PR adds a changelog entry announcing ClickHouse Cloud as a new OAuth sign-in provider on Langfuse Cloud, covering account creation, existing-account linking via matching email, and a pointer to the authentication docs.
ogImageand the<Frame>block (public/images/changelog/2026-05-14-sign-in-with-clickhouse-cloud.png) is absent from the repository; the page will render a broken image and produce a missing OG image until the screenshot is committed.Confidence Score: 3/5
Not safe to merge yet — the referenced screenshot is missing from the repository, which will produce broken images on the published changelog page.
The changelog entry itself is well-written and follows the established format, but the image asset does not exist in the repo. Both the ogImage frontmatter field and the inline Frame block point to it, so the page will render with a broken image and missing social-preview metadata the moment it goes live. Additionally, the Japan region — launched weeks earlier with documented full platform parity — is absent from the supported-regions list without explanation.
content/changelog/2026-05-14-sign-in-with-clickhouse-cloud.mdx — the missing image asset and the region list need to be resolved before publishing.
Sequence Diagram
sequenceDiagram actor User participant Langfuse as Langfuse Cloud Login participant CHCloud as ClickHouse Cloud OAuth User->>Langfuse: Click "Sign in with ClickHouse Cloud" Langfuse->>CHCloud: Redirect to ClickHouse Cloud OAuth User->>CHCloud: Authenticate CHCloud-->>Langfuse: Return OAuth token + email alt Email matches existing Langfuse account Langfuse->>Langfuse: Link ClickHouse Cloud identity to existing account Langfuse-->>User: Log in (projects, memberships, API keys carried over) else New email Langfuse->>Langfuse: Create new Langfuse account Langfuse-->>User: Log in (new account) endPrompt To Fix All With AI
Reviews (1): Last reviewed commit: "docs(changelog): announce Sign in with C..." | Re-trigger Greptile