I'll just post here a part of the email that I've sent to you, so other users would also have this info.
To be honest â€“ weâ€™re confused at the moment with the last list of bugs youâ€™ve reported. While we were aware of lots of issues in Pull process previously â€“ after the latest hotfix our internal Salesforce development team have not reported any issues with pull and we were unable to get any of them under a good stress testing that weâ€™ve done earlier last week. I also admit that some issues are also know (e.g. sometimes not working code outlining and Go to definition â€“ itâ€™s related to an Apex grammar that we have to build from scratch. Currently 2 team members are dedicated on fixing all the grammar issues and theyâ€™ve done a huge work in this direction).
Regarding tests taking so long â€“ this is caused by Salesforce returning us empty symbol table in some rare cases. Because weâ€™re unable to constantly reproduce this issue weâ€™re right now changing logic for Apex Tests fetching. Currently itâ€™s working in this way:
- Fetching info from Salesforce (this may take a lot of time)
- if thereâ€™s an empty response from Salesforce weâ€™re analyzing project content and taking tests from the project
- if thereâ€™s not empty response it is cached (so the next time weâ€™re not calling SF, weâ€™re using cached data) and used by Tests runner.
After the next release this process would be like this:
- If thereâ€™s no cache - scan project contents for tests and display them, while giving user the ability to manually initiate data fetch from Salesforce.
- If Salesforce returns not empty content â€“ itâ€™s cached
- If Salesforce returns empty content â€“ local data from the project is used
- If cache is available â€“ it would be displayed to the user.
I think that this approach will help you with tests execution, but I still donâ€™t think that itâ€™s the best solution (thereâ€™s a lot of confusion about what data would be used) and we will work on this process more in the future.
However some issues that youâ€™re reporting we havenâ€™t noticed previously at all (like crashing Pending changes panel, not functional conflicts resolving) and some of them are related to the core Visual Studio functionality (Search in Solution Explorer) â€“ which leads us to the situation when Iâ€™d want to ask you to provide us any additional info about your project, â€œtrickyâ€ moments in code (because of grammar issues Iâ€™ve mentioned before some â€œnot-so-commonâ€ code blocks may lead to unpredicted behavior of outlining and go to definition), your activities with the project, what changes are done on SF side and what changes are done on your side when pull is not working and so on.