Skip to content

Conversation

andrewyuq
Copy link
Owner

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Description

Checklist

  • My code follows the code style of this project
  • I have added tests to cover my changes
  • A short description of the change has been added to the CHANGELOG if the change is customer-facing in the IDE.
  • I have added metrics for my changes (if required)

License

I confirm that my contribution is made under the terms of the Apache 2.0 license.

Copy link

github-actions bot commented Sep 25, 2024

Qodana Community for JVM

27 new problems were found

Inspection name Severity Problems
Unused import directive 🔶 Warning 11
Unused symbol 🔶 Warning 8
Usage of redundant or deprecated syntax or deprecated symbols 🔶 Warning 3
Component/Action not registered 🔶 Warning 2
Constant conditions 🔶 Warning 2
Class member can have 'private' visibility ◽️ Notice 1

💡 Qodana analysis was run in the pull request mode: only the changed files were checked

View the detailed Qodana report

To be able to view the detailed Qodana report, you can either:

To get *.log files or any other Qodana artifacts, run the action with upload-result option set to true,
so that the action will upload the files as the job artifacts:

      - name: 'Qodana Scan'
        uses: JetBrains/[email protected]
        with:
          upload-result: true
Contact Qodana team

Contact us at [email protected]

* Track SessionContext instead of InvocationContext

1. Since the shift from displaying one trigger at a time
to displaying multiple triggers at a time, use SessionContext
as the disposable for the session states.
2. Introduce the concept of "display session" which can show
multiple triggers at a time and sessionContext is to hold states
for that session.
3. ongoingRequests will be a map of <jobId, InvocationContext>
where InvocationContext is the state of each trigger.
4. Managed these states globally by dynamically adding Trigger states
into ongoingRequests and whenever the user made a decision(accept or
reject), conclude decisions for all the ongoing triggers and clear
ongoingRequest, so that a new display session can start later.

* address comments
…ngs (aws#4914)

* Replace old actions with new actions that have configurable key bindings

1. Accept (Tab)
2. Force Accept (Opt + Tab/Opt + Enter)
3. Navigate to Previous (Opt + [)
4. Navigate to Next (Opt + ])

* put sessionConext as project userdata and remove states of the actions

* add popup keybinding hint and settings hyperlink

* Addressing comments
1. remove triggerOnIdle type code
2. address comments from previous PR
…/aws/toolkits/jetbrains/services/codewhisperer/service/CodeWhispererAutoTriggerService.kt

Co-authored-by: Richard Li <[email protected]>
@andrewyuq andrewyuq force-pushed the main branch 3 times, most recently from 5a466c4 to 5016751 Compare October 10, 2024 09:48
@andrewyuq andrewyuq force-pushed the main branch 2 times, most recently from 9788111 to bdc5544 Compare October 24, 2024 21:45
@andrewyuq andrewyuq force-pushed the main branch 2 times, most recently from df2a345 to f4d987a Compare January 17, 2025 19:17
andrewyuq pushed a commit that referenced this pull request Apr 23, 2025
Orphaned http request that should be rejected somehow sneaked into the http request event loop while the FAISS index is not ready, causing the workspace LSP process to terminate, which causes the JetBrains IDE to re-initialize the workspace LSP process, which further triggers an infinite loop of log storm that caused slowness (the log loop issue is fixed in aws#5581). 

Here are the sequence of events that happened:

1. JB starts workspace LSP, the LSP then works on tree sitter parsing to generate repomap.
2. When #1 is in progress, client (user) uses @workspace feature sends a request for vector index query. #1 is usually fast but for 1.4GB repo like https://github.com/elastic/elasticsearch (1.4GB), it takes 6 min. 
3. Node js event loop busy, client request #2 is timed out. However, requests is cached at server and it becomes an Orphaned http request.
4. The moment when tree sitter parsing is done, node js event loop SOMEHOW immediately handles the Orphaned request in step 2 at a certain possibility!
5. The vector index is not undefined, it was partially initialized, but it had no chunk inside, query when 0 chunks caused Faiss to crash, which terminated the LSP process.
6. JB saw java.net.ConnectException: Connection refused, it then forces LSP to restart, which restarts the indexing, causing performance issue.
@andrewyuq andrewyuq force-pushed the main branch 2 times, most recently from a5ca53f to 9ebb553 Compare May 14, 2025 01:28
@andrewyuq andrewyuq force-pushed the main branch 2 times, most recently from a87a064 to 02cc324 Compare June 11, 2025 21:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant