sst
Unbounded LSP output may use entire token quota
Description
You'll see bash.ts has some mechanisms for limiting its output, we may want the same in write.ts, namely, where it processes the response of the language server call here
I was pointed in this direction here: https://github.com/sst/opencode/issues/2464#issuecomment-3583939028
In my particular case, it may ask the language server to fully inspect a repo, and trigger tons of errors due to the language server not knowing about a particular plugin or config ("Lombok" in my case, for java). Ultimately best solved by configuring the LSP appropriately on my end, but I don't think we ever want this code adding an unbounded amount of data to the context, right?
Would a pattern similar to bash.ts make sense?
OpenCode version
No response
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
This issue might be a duplicate of existing issues. Please check:
- #4826: [Question] Is automatic tool calling output truncation supported? - directly addresses truncation of unbounded tool output to prevent token quota issues
- #4560: [FEATURE]: Context protection for tool calls when response is large - proposes automatic detection and handling of large tool responses
- #5178: [FEATURE]: Allow continuation after context overflow - related to handling context overflow scenarios
- #2464: AT_APICallError: prompt token count exceeds limit - real-world case of token quota being exceeded
- #4315: Memory stays unbounded - related issue about tool output memory management
Feel free to ignore if none of these address your specific case.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Some of the suggested dupes are valid, for a general pattern to follow for tools. This issue could conceivably stick around if a focused solution is desired around LSP output maybe?
I was thinking we cap the # of diagnostics to show
Are your diagnostics huge? Or would that work
I'll have to tinker to get it to show up again, i think what i saw was hundreds of individual files were flagged with various compiler issues because the java LSP didnt understand some annotations. I'm not 100% sure how how that was represented in the data model in write.ts. I'll tinker later with a local debug build perhaps.
Sounds good, I think normally each diagnostic isn't insanely big and we can just grab the top 20 or so (or just the highest severity ones). And that should do it.
Happy to do that for you we talked about it internally once but forgot about it
