Tracing the error source

If the issue you are facing is new and didn't exist in the past, use the Binary Search debugging process presented in the following to find where in time and which changes to the code caused this new bug.

Notice that the FastStore development workflow is Git-based, meaning developers must create a commit on the store's main branch for each new release. This action generates a release timeline which you can use to go back to previous versions of your store and test if the issue was already happening in the past.

If your feature was working correctly in the past, you will certainly find which version of your store introduced this error. You'll also be able to tell exactly which files and code changes caused the issue.

Step by Step

To speed up the process of going back in time, checking version by version of your store, you can use a strategy called Binary Search, which is available via the bisect Git feature. Below, we present a step by step on how to use git bisect with FastStore.

Open the terminal on your project's root and run the following command to list all commits made in your repository:
```
git log
```
Copy the hash of a commit that worked properly in the past.
Use binary search to find the commit that introduced the bug:
- Replace {commitHash} with the hash value you copied in the previous step.
```
git bisect start HEAD {commitHash}
```
Start a local development server to test this previous version of your store:
```
yarn && yarn develop
```
Access your localhost using the browser and test your features.

If everything works as expected, bisect your project as in the following:

git bisect good

Otherwise, if that version is broken, run the following command:

git bisect bad

After a few iterations, Git will find the bad version for you. Then, after identifying this version, use git diff to detect the changes that caused the issue.

Related resources

Identifying Development Errors and Starter Bugs FastStore UI