Add a check to the proto scripts to warn about using int64 types. #5174
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Coverage ReportExtension CoverageBase branch: 46% PR branch: 47% ✅ Coverage increased or remained the same Webview CoverageBase branch: 17% PR branch: 17% ✅ Coverage increased or remained the same Overall Assessment✅ Test coverage has been maintained or improved Last updated: 2025-07-28T02:02:12.479181 |
Garoth
approved these changes
Jul 26, 2025
canvrno
reviewed
Jul 27, 2025
Javascript cannot represent the full range of int64. So, when the protos are deserialized from JSON int64's are converted to strings. The typescript code is expecting a number and not a string, and this causes errors. This was noticed before now because in the vscode protobus and hostbridge, the proto messages are not serialized and deserialized, they are just passed around as JS objects. However, in IntelliJ the protos are serialized when they are sent through the ProtoBus. When the response messages contains and int64, it is deserialized to a string instead of a number for safety. This is causes parts of Cline to fail in IntelliJ, e.g. the task history view won't load because `Task.getTotalTasksSize()` returns a string when it is expecting a number.
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
Garoth
approved these changes
Jul 28, 2025
canvrno
approved these changes
Jul 28, 2025
canvrno
approved these changes
Jul 28, 2025
sjf
added a commit
that referenced
this pull request
Jul 28, 2025
…t32. As described [here](#5174), int64 cannot be deserialized directly into numbers in Typescript. Switch these timeout and line limit fields to int32 because the range of values should fit in int32. Replace the Int64Request and response in the RPC `updateTerminalConnectionTimeout` with request and response messages for this RPC. It is the best practise to have unique request/response messages for each RPC because it means you can update the request or response easily because the messages are not shared with other RPCs. The fields can also have self-documenting names instead of the generic `value` field name.
sjf
added a commit
that referenced
this pull request
Jul 28, 2025
…t32. As described [here](#5174), int64 cannot be deserialized directly into numbers in Typescript. Switch these timeout and line limit fields to int32 because the range of values should fit in int32. Replace the Int64Request and response in the RPC `updateTerminalConnectionTimeout` with request and response messages for this RPC. It is the best practise to have unique request/response messages for each RPC because it means you can update the request or response easily because the messages are not shared with other RPCs. The fields can also have self-documenting names instead of the generic `value` field name.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Javascript cannot represent the full range of int64. So, when the protos are deserialized from JSON the int64's are converted to strings for safety. However, typescript code is expecting a number and not a string, and this is causing problems.
This was not noticed before now because in the Vscode ProtoBus and HostBridge, the proto messages are not serialized and deserialized, they are just passed around as JS objects.
However, in the external HostBridge the protos are serialized when they are sent through the ProtoBus. When the response messages contain an int64, it is deserialized to a string instead of a number for safety. This is causing parts of Cline to fail, e.g. the task history view won't load because
Task.getTotalTasksSize()returns a string when the caller is expecting a number.Update the proto code generation scripts so they are all run from the main
build-proto.mjsscript.Don't show the full warning output unless the script is run with -v because there are currently too many warnings.
Type of Change
Pre-flight Checklist
npm test) and code is formatted and linted (npm run format && npm run lint)npm run changeset(required for user-facing changes)Screenshots
Additional Notes
Important
Adds int64 type check in proto scripts, consolidates script execution, and modifies warning verbosity.
checkProtos()inbuild-proto.mjsto warn about int64 types in proto files, logging warnings for fields using 64-bit integers.build-proto.mjsto rungenerate-protobus-setup.mjsandgenerate-host-bridge-client.mjsfrommain().-vflag is used.main()ingenerate-host-bridge-client.mjsandgenerate-protobus-setup.mjsfor external invocation.package.jsonto run all proto scripts frombuild-proto.mjs.loadProtoDescriptorSet()inproto-utils.mjsfor loading proto descriptor sets.This description was created by
for a04beca. You can customize this summary. It will automatically update as commits are pushed.