Repository navigation
KCL: Send version when connecting to engine - #13920
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Merging this PR will degrade performance by 20.49%
|
| Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|
| ❌ | no_engine_mock_execute_mike_stress_test[3000] |
8.7 s | 11 s | -20.49% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing achalmers/send-kcl-version (31b5d24) with main (0b6e129)2
Footnotes
-
129 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩
-
No successful run was found on
main(3185633) during the generation of this report, so 0b6e129 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩
2b590a5 to
ca18fc2
Compare
ca18fc2 to
098c230
Compare
Adam: When creating a WebSocket connection to the engine, either in native Rust (via Tungstenite) or in the browser's WebSocket, we need to send the KCL Version being used, in the `CommandsWsParams` struct that is serialized into the WebSocket URL's query string. I'd like one centralized place that we can read the KCL version from. Currently this is just the annotations of the KCL entrypoint (the first file executed). We need some place for the KCL version to be read by both the KCL runtime itself (which needs to know the version to know what KCL language behaviour to do) and by the frontend (which needs to connect to the engine and send the KCL version in its connection URL). Both KCL and the frontend will need to know the KCL version before execution begins. Implemented: the frontend sends kcl_version using the shared Rust/Wasm resolver and reconnects when the entrypoint version changes. Legacy runtime behavior is preserved.
Now the KCL `@settings` header is parsed early, to get the KCL version before connecting to engine. This means errors in the `@settings` block, like putting `nm` as the units (we do not support nanometers), get checked earlier before establishing connection. Sim test artifact change reflects this.
098c230 to
fd4c2ab
Compare
This branch was successfully deployed
2 participants
Closes #11526