Skip to content

fix(sessions): add cancel control to cloud initializing screen #2621

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
posthog wants to merge 1 commit into
base: main
Choose a base branch
from
+98 −2
Draft

fix(sessions): add cancel control to cloud initializing screen #2621

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
72 changes: 72 additions & 0 deletions packages/ui/src/features/sessions/components/CloudInitializingView.test.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,72 @@
import { Theme } from "@radix-ui/themes";
import { act, render, screen } from "@testing-library/react";
import { afterEach, beforeEach, describe, expect, it, vi } from "vitest";
import { CloudInitializingView } from "./CloudInitializingView";

// The view hides everything behind a 2s reveal delay; fast-forward past it so
// the heading and controls are mounted.
function reveal() {
act(() => {
vi.advanceTimersByTime(2000);
});
}

describe("CloudInitializingView", () => {
beforeEach(() => {
vi.useFakeTimers();
});

afterEach(() => {
vi.useRealTimers();
});

it("renders a cancel control while provisioning when onCancel is provided", () => {
render(
<Theme>
<CloudInitializingView cloudStatus={null} onCancel={() => {}} />
</Theme>,
);
reveal();
expect(screen.getByText("Getting things ready…")).toBeInTheDocument();
expect(
screen.getByRole("button", { name: "Cancel" }),
).toBeInTheDocument();
});

it("omits the cancel control when no handler is provided", () => {
render(
<Theme>
<CloudInitializingView cloudStatus="queued" />
</Theme>,
);
reveal();
expect(
screen.queryByRole("button", { name: "Cancel" }),
).not.toBeInTheDocument();
});
Comment on lines +23 to +46

@greptile-apps greptile-apps Bot Jun 11, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 The first two tests cover the same boolean condition (onCancel provided vs omitted) and their assertions mirror each other. Per the team's parameterised-test preference these could be collapsed into a single it.each, e.g. [[null, true], [undefined, false]] — keeping the shared setup in one place and making it easy to add more cloudStatus/onCancel combinations later.

Prompt To Fix With AI 
This is a comment left during a code review.
Path: packages/ui/src/features/sessions/components/CloudInitializingView.test.tsx
Line: 23-46

Comment:
The first two tests cover the same boolean condition (`onCancel` provided vs omitted) and their assertions mirror each other. Per the team's parameterised-test preference these could be collapsed into a single `it.each`, e.g. `[[null, true], [undefined, false]]` — keeping the shared setup in one place and making it easy to add more `cloudStatus`/`onCancel` combinations later.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!


it("invokes onCancel once and shows a pending label on click", () => {
const onCancel = vi.fn();
render(
<Theme>
<CloudInitializingView cloudStatus="queued" onCancel={onCancel} />
</Theme>,
);
reveal();

const button = screen.getByRole("button", { name: "Cancel" });
act(() => {
button.click();
});

expect(onCancel).toHaveBeenCalledTimes(1);
const pending = screen.getByRole("button", { name: "Cancelling…" });
expect(pending).toBeDisabled();

// A second click is a no-op while the cancel is in flight.
act(() => {
pending.click();
});
expect(onCancel).toHaveBeenCalledTimes(1);
});
});
23 changes: 22 additions & 1 deletion packages/ui/src/features/sessions/components/CloudInitializingView.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,11 +1,13 @@
import { Spinner } from "@phosphor-icons/react";
import type { TaskRunStatus } from "@posthog/shared/domain-types";
import { Flex, Text } from "@radix-ui/themes";
import { Button, Flex, Text } from "@radix-ui/themes";
import { useEffect, useState } from "react";
import zenHedgehog from "../../../assets/images/zen.png";

interface CloudInitializingViewProps {
cloudStatus: TaskRunStatus | null;
/** Cancels the provisioning cloud run. When omitted, no cancel control is shown. */
onCancel?: () => void;
}

const REVEAL_DELAY_MS = 2000;
Expand Down Expand Up @@ -35,15 +37,23 @@ function copyFor(cloudStatus: TaskRunStatus | null): {

export function CloudInitializingView({
cloudStatus,
onCancel,
}: CloudInitializingViewProps) {
const { heading, subtitle } = copyFor(cloudStatus);

const [revealed, setRevealed] = useState(false);
const [cancelling, setCancelling] = useState(false);
useEffect(() => {
const timer = setTimeout(() => setRevealed(true), REVEAL_DELAY_MS);
return () => clearTimeout(timer);
}, []);

const handleCancel = () => {
if (cancelling) return;
setCancelling(true);
onCancel?.();
};
Comment on lines +51 to +55

@greptile-apps greptile-apps Bot Jun 11, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 The if (cancelling) return guard is redundant — React does not fire onClick on a disabled button, so the check can never be reached once cancelling is true. The "Cancelling…" label and disabled attribute on the button are already the single point of protection. This violates the "no superfluous parts" simplicity rule, and the duplicate guard also means the same invariant is expressed in two places (once in the handler, once in the JSX).

Suggested change
const handleCancel = () => {
if (cancelling) return;
setCancelling(true);
onCancel?.();
};
const handleCancel = () => {
setCancelling(true);
onCancel?.();
};
Prompt To Fix With AI 
This is a comment left during a code review.
Path: packages/ui/src/features/sessions/components/CloudInitializingView.tsx
Line: 51-55

Comment:
The `if (cancelling) return` guard is redundant — React does not fire `onClick` on a `disabled` button, so the check can never be reached once `cancelling` is `true`. The "Cancelling…" label and `disabled` attribute on the button are already the single point of protection. This violates the "no superfluous parts" simplicity rule, and the duplicate guard also means the same invariant is expressed in two places (once in the handler, once in the JSX).

```suggestion
  const handleCancel = () => {
    setCancelling(true);
    onCancel?.();
  };
```

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Comment on lines 44 to +55

@greptile-apps greptile-apps Bot Jun 11, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 cancelling is never reset to false. If onCancel is invoked but the underlying request fails (and the component stays mounted in the initialising state), the button is permanently locked in "Cancelling…" with no retry path. Because onCancel is typed as () => void, the caller can't surface a failure back here. Consider widening the signature to onCancel?: () => Promise<void> and resetting cancelling in a catch, or at minimum resetting it in finally, so a failed cancel attempt doesn't permanently disable the control.

Prompt To Fix With AI 
This is a comment left during a code review.
Path: packages/ui/src/features/sessions/components/CloudInitializingView.tsx
Line: 44-55

Comment:
`cancelling` is never reset to `false`. If `onCancel` is invoked but the underlying request fails (and the component stays mounted in the initialising state), the button is permanently locked in "Cancelling…" with no retry path. Because `onCancel` is typed as `() => void`, the caller can't surface a failure back here. Consider widening the signature to `onCancel?: () => Promise<void>` and resetting `cancelling` in a `catch`, or at minimum resetting it in `finally`, so a failed cancel attempt doesn't permanently disable the control.

How can I resolve this? If you propose a fix, please make it concise.


if (!revealed) {
return (
<Flex
Expand Down Expand Up @@ -76,6 +86,17 @@ export function CloudInitializingView({
{subtitle}
</Text>
</Flex>
{onCancel && (
<Button
variant="soft"
color="gray"
size="2"
onClick={handleCancel}
disabled={cancelling}
>
{cancelling ? "Cancelling…" : "Cancel"}
</Button>
)}
</Flex>
);
}
5 changes: 4 additions & 1 deletion packages/ui/src/features/sessions/components/SessionView.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -458,7 +458,10 @@ export function SessionView({
</>
) : isInitializing ? (
isCloud ? (
<CloudInitializingView cloudStatus={cloudStatus} />
<CloudInitializingView
cloudStatus={cloudStatus}
onCancel={onCancelPrompt}
/>
) : pendingTaskPrompt?.promptText ? (
<PendingChatView
promptText={pendingTaskPrompt.promptText}
Expand Down
Loading