Skip to content

fix: ui: workspace bumpers now honour template max_ttl #3532

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.

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

Merged
merged 15 commits into from
Aug 18, 2022

Conversation

johnstcn
Copy link
Member

@johnstcn johnstcn commented Aug 17, 2022

  • chore: WorkspacePage: invert workspace schedule bumper logic for readibility
  • fix: ui: workspace bumpers now honour template max_ttl
  • chore: refactor workspace schedule bumper logic mostly into util/schedule.ts and unit test separately

Verification Steps:

  • Create and start a workspace from a template that has a max_ttl of less than 24 hours and has autostop enabled.
  • Repeatedly click the ➕ icon by the schedule -> it should not allow extending the workspace deadline past template max_ttl
  • Repeatedly click the ➖ icon by the schedule -> it should not allow decreasing the workspace deadline before now plus 30 minutes

Fixes #2764.

@johnstcn johnstcn self-assigned this Aug 17, 2022
Comment on lines -43 to -52
export const deadlineMinusDisabled = (workspace: Workspace, now: dayjs.Dayjs): boolean => {
const delta = dayjs(workspace.latest_build.deadline).diff(now)
return delta <= 30 * 60 * 1000 // 30 minutes
}

export const deadlinePlusDisabled = (workspace: Workspace, now: dayjs.Dayjs): boolean => {
const delta = dayjs(workspace.latest_build.deadline).diff(now)
return delta >= 24 * 60 * 60 * 1000 // 24 hours
}

Copy link
Member Author

@johnstcn johnstcn Aug 18, 2022

Choose a reason for hiding this comment

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

review: moved to util/workspace.ts
EDIT: actually moved to util/schedule.ts which is a more sensible place for it

@johnstcn johnstcn marked this pull request as ready for review August 18, 2022 15:05
@johnstcn johnstcn requested a review from a team as a code owner August 18, 2022 15:05
@johnstcn johnstcn changed the title WIP: fix: ui: workspace bumpers now honour template max_ttl fix: ui: workspace bumpers now honour template max_ttl Aug 18, 2022
{checkPermissionsError && <ErrorSummary error={checkPermissionsError} />}
</div>
)
} else if (!workspace) {
return <FullScreenLoader />
} else if (!template) {
return <div className={styles.error}>Loading template</div>
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this should be treated as a loading state like !workspace. I'm assuming that if fetching it failed, we'll have an error.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's fair. Although I'd really like to be able to add information to FullScreenLoader on what's currently happening (e.g. Reticulating Splines)

Copy link
Contributor

Choose a reason for hiding this comment

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

We could add a prop to FullScreenLoader that can take that info?

Copy link
Member Author

Choose a reason for hiding this comment

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

That sounds like a good idea. I'll open a separate issue for that.

@@ -181,6 +183,7 @@ describe("Workspace Page", () => {

describe("Resources", () => {
it("shows the status of each agent in each resource", async () => {
const getTemplateMock = jest.spyOn(api, "getTemplate").mockResolvedValueOnce(MockTemplate)
Copy link
Contributor

Choose a reason for hiding this comment

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

It's generally better to test things that are apparent to the user than internals like whether a function was called, but sometimes it's necessary. Is this one of the cases where testing user-apparent effects is too hard?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not sure -- I'll try seeing if I can make some assertions about child components here.

Copy link
Member Author

Choose a reason for hiding this comment

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

Actually, it seems like testing properties of child components is considered somewhat of an anti-pattern. I'll factor some more stuff out to a util file and test it separately.

@@ -85,7 +91,7 @@ export const WorkspacePage: React.FC = () => {
bannerSend({
type: "UPDATE_DEADLINE",
workspaceId: workspace.id,
newDeadline: dayjs(workspace.latest_build.deadline).utc().add(4, "hours"),
newDeadline: dayjs.min(deadline.add(4, "hours"), maxDeadline(workspace, template)),
Copy link
Contributor

Choose a reason for hiding this comment

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

You don't have to change this here, but I'm wondering if we want to try to push logic like this into XState. Instead of one UPDATE_DEADLINE event, we could have multiple events that do calculations within them. The idea would be to try to get more logic out of components. Maybe a topic for Frontend Variety.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I was wondering that but didn't want to over-complicate the machine. :-)

@@ -1,10 +1,14 @@
import { Theme } from "@material-ui/core/styles"
import dayjs from "dayjs"
import duration from "dayjs/plugin/duration"
Copy link
Contributor

Choose a reason for hiding this comment

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

Love that you put util functions in their own spot and tested them! I noticed when I was working on the schedule form that there are a lot of different places for schedule-related util functions. Any thoughts on that? I don't want to make you figure it all out in this PR but I might at least call this util file something about the schedule instead of just the workspace.

Copy link
Member Author

@johnstcn johnstcn Aug 18, 2022

Choose a reason for hiding this comment

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

IMO I think it makes sense to keep it in the workspace util file, as workspaces and schedules are tightly coupled. If we eventually move schedules into more of a separate entity of their own, then maybe I could see it making more sense.

EDIT: Silly me, I forgot about util/schedule.ts. Moving things in there.

Copy link
Contributor

@presleyp presleyp left a comment

Choose a reason for hiding this comment

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

Great work! The loading state is the only thing I feel strongly about.

@johnstcn johnstcn force-pushed the cj/gh-2764/fix-workspace-bumpers branch from 3a16557 to e69ff7f Compare August 18, 2022 22:17
@johnstcn johnstcn merged commit 04c5f92 into main Aug 18, 2022
@johnstcn johnstcn deleted the cj/gh-2764/fix-workspace-bumpers branch August 18, 2022 22:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Workspace schedule bumpers are broken
2 participants