Prevent going back to previous session when changing modes on a new initialized session

[uinstinct]

Description

This happens when we change the modes. Currently when we open a new session by clicking on the new session button, we go back to the previous session as we change mode from edit to chat/agent.

This should not happen because the user explicitly asked for a new chat session.

This PR fixes this by tracking when a new session was explicitly initialized then we do not go back to previous sessions on any mode change.

Checklist

• [] I've read the contributing guide
• [] The relevant docs, if any, have been updated or created
• [] The relevant tests, if any, have been updated or created

Screenshots

before.mp4

after.mp4

Testing instructions

1. Click on a new chat session plus button on the top right.
2. Change the mode to edit.
3. Now change the mode to chat or agent.
4. See that new session is preserved without going back to the previous session unexpectedly.

[netlify]

✅ Deploy Preview for continuedev ready!

Name	Link
🔨 Latest commit	7ae7827
🔍 Latest deploy log	https://app.netlify.com/sites/continuedev/deploys/680b0f873a7741000831c70e
😎 Deploy Preview	https://deploy-preview-5357--continuedev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[sestinj]

@uinstinct thanks as always for the clear videos!

I've noticed that a lot of your PRs have been great candidates for some of the improved testing setup we've worked on in the last week (e.g. https://github.com/continuedev/continue/blob/8ed59cfbc17169fca7d95e72f7e8da11b3fac4d4/gui/src/pages/history/history.test.tsx). In any future GUI-related changes, we'd love to see tests or if you find them difficult to write, please let me know! There's probably more work we can do to improve the tooling and feedback would be great

[uinstinct]

Thanks @sestinj for your appreciation!
Yes, i will add tests to the pull requests from now on. I find the unit tests easy to write and run.
The e2e tests in the vscode directory are harder to run locally. I prefer github actions for running them which take time. Hence, prefer to skip e2e tests 😅
Can you please point me the direction which should be followed to get the e2e tests setup locally?

errors when running e2e tests locally on the main branch

when doing `npm run e2e:all` inside extensions/vscode, the following error pops up

Browser ready in 5831 ms
Launching tests...
  Edit Test
    1) "before all" hook for "Accepts an Edit in the GUI"

Shutting down the browser

  0 passing (25s)
  1 failing

  1) Edit Test
       "before all" hook for "Accepts an Edit in the GUI":
     ElementNotInteractableError: element not interactable
  (Session info: chrome=128.0.6613.186)
      at Object.throwDecodedError (node_modules/selenium-webdriver/lib/error.js:521:15)
      at parseHttpResponse (node_modules/selenium-webdriver/lib/http.js:514:13)
      at Executor.execute (node_modules/selenium-webdriver/lib/http.js:446:28)
      at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
      at async Driver.execute (node_modules/selenium-webdriver/lib/webdriver.js:744:17)
      at async InputBox.findQuickPick (node_modules/@redhat-developer/page-objects/out/components/workbench/input/Input.js:173:17)
      at async InputBox.selectQuickPick (node_modules/@redhat-developer/page-objects/out/components/workbench/input/Input.js:113:22)
      at async Workbench.executeCommand (node_modules/@redhat-developer/page-objects/out/components/workbench/Workbench.js:143:13)
      at async GlobalActions.createAndOpenNewTextFile (e2e/_output/actions/Global.actions.js:18:9)
      at async Context.<anonymous> (e2e/_output/tests/Edit.test.js:20:23)

---

BTW, please feel free to tag me on fix or feat related issues. Happy to help and pick them up. Really like to work on Continue.

[sestinj]

@uinstinct I actually agree e2e tests are a bit unwieldy at the moment 😅

Luckily, there's a different and easier to work with testing suite that I'm referring to. If you run npm run test from the gui directory, it uses vitest to do unit testing on the UI.

Recently I configured it so that you can mock the entire core/IDE, so most of the tests should be able to run very quickly and standalone. There's a good short example here, but I'll be working on better documentation in CONTRIBUTING.md very soon