Skip to content

Conversation

@filiptronicek
Copy link
Member

Description

Make sure we don't hang too long when opening files. This can for instance happen when you've got the workspace open in both browser and desktop and supervisor is trying to open it in the editor you don't have in focus.

Related Issue(s)

Fixes https://gitpod.slack.com/archives/C04JEP60Q9X/p1731952414858989?thread_ts=1731952175.327349&cid=C04JEP60Q9X

/hold

@roboquat roboquat merged commit 28942bd into main Nov 18, 2024
17 checks passed
@roboquat roboquat deleted the ft/proper-gp-open-timeouts branch November 18, 2024 19:09

if wait {
pargs = append(pargs, "--wait")
ctx = cmd.Context()
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: there're ctx used before this line, like client.WaitForIDEReady(ctx). If a use passed --wait flag, it will not wait IDE to be ready after '10 seconds of not ready' then returns an error.

(But the original code has this issue as well, so I'm not sure if this is an intended feature)

Copy link
Member Author

Choose a reason for hiding this comment

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

@mustard-mh looking at the code again, it seems fine to use the timeout-enabled context everywhere besides the final call to the editor binary, since we want to be able to time out on the other operations that are not expected to run potentially indefinitely.

Running the following inside the gitpod-cli directory seems to behave as expected, even when taking more than 10s to close the file:

go run . open --wait main.go 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants