starship: Introduce a timeout for module load time

Feature Request

Is your feature request related to a problem? Please describe.

We have quite a few issues open right now (#283 #295 #301 #304) describing issues with starship performance not cause by starship itself, but by the fact that access to the underlying filesystem is slow, unreliable, or impossible.

Describe the solution you’d like

Implement a per-module timeout that will kill the module if it takes too long to render. We should also include the option to render a string in case the module times out.

[git_status]
timeout = 300
timeout_message = "GS_TO"

Describe alternatives you’ve considered

The generally-desirable solution here would be to use a standalone caching process, a caching file (updated asynchronously), or asynchronous rendering to allow the user to start inputting commands before all the information has been retrieved. However, my first impression is that all of these would require a fairly significant overhaul of how starship handles filesystem access.

About this issue

Original URL
State: open
Created 5 years ago
Reactions: 7
Comments: 19 (13 by maintainers)

Most upvoted comments

So I guess this would go in the prompt section, something like

[prompt]
timeout=300
timeout_message=TIMEDOUT

chipbuster on Sep 7, 2019

I personally feel that per-module timeout configuration timeout might be a little too granular and wouldn’t be useful to the majority of users.

What about having a global timeout configuration option that applies to every module?

matchai on Sep 7, 2019

I have this problem with FUSE and gvfs-ssh which makes the prompt unusable.

you cannot kill an IO bound process. Even if I know that starship is hanging due to a pending synchronous read, I can do nothing to kill it. Sending SIGKILL will not kill starship because the signal is delivered asynchronously, meaning that the IO has to be cancelled before the signal can be received. There is no way to do this on Linux.
you cannot “temporarily” disable starship. Apparently once you ran eval $(starship init bash) you can no longer override PS1 manually, so I can’t even disable starship before going into the FUSE mounted directory.

A straightforward solution would be allowing user to disable all or some starship modules on certain directories.

takase1121 on Sep 5, 2022