To help make sure we can diagnose, group, and ultimately fix issues quickly it’s important that we collect relevant information. This document will give plenty of tips to help collect data outside of a Cody dev environment.
<aside> 🎯 Our goal is not just for an issues to be fixed. We want to:
1. Go from “report” to “reproducible test” ASAP We can leverage good descriptions and relevant context information to guide us, but until we can reliably replicate the issue in code we’re flying blind.
This is often the biggest hurdle; so even if you don’t know how to fix an issue, if you’re able to write a unit or e2e for it you’ve contributed 80% of the work (and will receive appropriate kudos)!
(As a side benefit, Cody is much better at assisting with writing a fix for the problem if you already have the problem captured in a test)
2. Focus on Impact Once an issue is accurately captured there’s likely a cluster of other similar reports and symptoms that have been created. Clustering those can help bring additional edge-cases or bump the importance.
Having a good test also makes it much easier to identify if there are underlying problems that need to be addressed.
3. Be kind to our future self Once the issue is fixed there’s no better time to spend a bit of extra time leverage all the information available to turn the “reproduction test” into a feature.
Maybe add some additional cases, improve the type-checking, or add a benchmark. Anything to guard against any future regressions but also to prevent similar bugs in the future.
</aside>
<aside> 🚧 Big improvements to the logger and exports are underway.
</aside>
In your VSCode settings make sure to set cody.debug.verbose to true to record more logging information.
<aside> ⚠️ Reload your VSCode window to actually enable the new settings. This will be improved soon.
</aside>
In the Command window (Cmd/Ctrl + Shift + P by default) you can also find a few helpful debugging tools including to view and export the logs.
<aside> ⚠️ Currently logs might still contain PII or other sensitive information so be careful who you share them with. This will be improved soon.
</aside>
In the Command window (Cmd/Ctrl + Shift + P by default) you can find a Autocomplete Trace View command. This opens a new tab that every time an autocomplete is triggered by you writing some code will show exactly what happened and how long it took.
If things seem to be slow or hanging it could be a helpful to get an idea of where time is spent in the Cody extension. A quick way to do so is to record a cpuprofile which tracks exactly which functions are called and how long the are running for.
👉 In VSCode open the command prompt (Cmd/Ctrl + Shift + P by default) and type “Developer: Show Running Extensions”. This will open up a list.
👉 Find the Cody extension, right click, and select “Start Extension Host Profile”. This will start the recording process. You can see this by looking in the bottom right of your window where you can now see a little notice.
👉 While recording try and perform the actions that were causing your problems. Once you have re-produced the issue you can click the little notice in the bottom right of the window to stop the recording.