Skip to content
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

Stale errors for a few minutes after switching branches #44066

Closed
OliverJAsh opened this issue May 13, 2021 · 10 comments
Closed

Stale errors for a few minutes after switching branches #44066

OliverJAsh opened this issue May 13, 2021 · 10 comments
Assignees
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@OliverJAsh
Copy link
Contributor

OliverJAsh commented May 13, 2021

Bug Report

🔎 Search Terms

performance vs code stale error switch branches git

🕗 Version & Regression Information

  • This is the behavior in every version I tried, and I reviewed the FAQ for entries about code editing

💻 Code

Video demonstration: https://www.loom.com/share/b8accd596ea74f16ae41f524e6e1497f
TS server log: tsserver.log

  1. Clone and checkout https://github.com/unsplash/unsplash-web/tree/typescript-stale-errors-a, branch typescript-stale-errors-a. This is a private repository but I believe some members of the TS team already have access from debugging previous issues. If you don't have access, please send me your email address so I can provide access (TS team members only).
  2. Run yarn
  3. Open VS Code and navigate to app/routes/Users/components/UserStatsSubRoute/UserStatsSubRoute.tsx
  4. Wait for VS Code to finish initialising TS (no errors)
  5. Switch branches: git checkout typescript-stale-errors-b

🙁 Actual behavior

Stale errors in the open file for about 2 minutes.

🙂 Expected behavior

  • No stale errors.
  • Some indication that TypeScript is updating in the background.
  • The update shouldn't take 2 minutes. Restarting TS server only takes ~20 seconds in comparison.

Related: microsoft/vscode#122928

@sheetalkamat
Copy link
Member

@OliverJAsh The branch is no longer available. Are you still seeing the issue. If yes can you please provide the steps to repro
Thanks

@sheetalkamat sheetalkamat added Needs More Info The issue still hasn't been fully clarified and removed Needs Investigation This issue needs a team member to investigate its status. Rescheduled This issue was previously scheduled to an earlier milestone labels May 3, 2022
@OliverJAsh
Copy link
Contributor Author

@sheetalkamat Sorry about that, I've pushed the branch again.

@sheetalkamat sheetalkamat added Needs Investigation This issue needs a team member to investigate its status. and removed Needs More Info The issue still hasn't been fully clarified labels May 4, 2022
@sheetalkamat
Copy link
Member

@OliverJAsh thank you for the repro.

While investigating this the root cause of this is that we poll 32 files at a time every 2 seconds. Since your project has 2000+ files being watched it takes a while for it to show up. At this point this looks working as intended.

@sheetalkamat sheetalkamat added Working as Intended The behavior described is the intended behavior; this is not a bug and removed Needs Investigation This issue needs a team member to investigate its status. labels May 4, 2022
@OliverJAsh
Copy link
Contributor Author

OliverJAsh commented May 4, 2022

Is there anything that could be done to improve the user experience? It seems quite extreme to wait this long for TS to fully update. To workaround this I have to restart the TS server very often.

Note that if I add these VS Code settings the issue disappears, i.e. there are no stale errors when I switch branch:

    "typescript.tsserver.watchOptions": {
        "watchFile": "useFsEvents",
        "watchDirectory": "useFsEvents"
    },

Perhaps this should be the default?

@sheetalkamat
Copy link
Member

I am trying to fix some of the issues with using file system watching since they are not reliable. After fix for #47466 , we could consider that but after we have tried it out. Eg. linux has some limit on number of file system watchers it can create.. Then there is non reliability because of watching inode.. though fix for #47466 will make it better but we will have to see how the experience is with that one.

@OliverJAsh
Copy link
Contributor Author

In that case should we keep this issue open to track the user experience issue?

@typescript-bot
Copy link
Collaborator

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

@OliverJAsh
Copy link
Contributor Author

OliverJAsh commented May 25, 2022

I understand this is working as intended but I think there is still a usability issue here. Can we re-open this to track that?

@OliverJAsh
Copy link
Contributor Author

OliverJAsh commented Sep 9, 2022

@sheetalkamat I just tested this again using TS 4.8 which includes #48997, the fix for #47466 which is mentioned above. Unfortunately the issue persists—it still takes 2 minutes for the stale errors to disappear. Do you think we could re-open this issue and discuss ways to improve the user experience?

As I mentioned above, if I add these VS Code settings the issue disappears, i.e. there are no stale errors when I switch branch. Do you think we could consider making these settings the default now that #47466 has been addresssed?

    "typescript.tsserver.watchOptions": {
        "watchFile": "useFsEvents",
        "watchDirectory": "useFsEvents"
    },

Let me know if you need an updated repro that uses TS 4.8.

@sheetalkamat
Copy link
Member

4.8 fix was more towards linux which was one of the blocker to make useFsEvents default.

useFsEvents is default now with #50366 and is in nightly.
@DanielRosenwasser is looking to see if we could get this as experiment in vscode for 4.8 users but it may take some time to get everything together or not work out at all. Mean time nightly will give you that experience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

5 participants