* Add in a Metrics request/response handler
Signed-off-by: Paul Tagliamonte <paul@kittycad.io>
* Update @kittycad/lib to 0.0.37
Signed-off-by: Paul Tagliamonte <paul@kittycad.io>
* Fix up type issues
Signed-off-by: Paul Tagliamonte <paul@kittycad.io>
* yarn fmt
* Remove VITE_KC_CONNECTION_WEBRTC_REPORT_STATS_MS
Signed-off-by: Paul Tagliamonte <paul@kittycad.io>
---------
Signed-off-by: Paul Tagliamonte <paul@kittycad.io>
Co-authored-by: Kurt Hutten <k.hutten@protonmail.ch>
The Promises are created behind a shouldTrace, so they'll be undefined
if you shouldn't be tracing. As a result, we need to guard the resoluton
of the promises.
Thanks @mlfarrell for spotting this in local dev!
Signed-off-by: Paul Tagliamonte <paul@kittycad.io>
* Redo how Spans are used from the Engine
I don't like all the Sentry-specific stuff we've got to work around, and
I want to add a bunch more spans and more cleanly end the transaction.
This isn't generic enough to pull out of this code (yet?), but we
clearly need some class of abstraction due to the highly async pattern
in the WebRTC code.
I want to add in more tags, but there are a lot of events we need to
wait on. I'd like to hook into the <video> 'play' eventListener, but
it's hard to do from all the way down in the Engine.
Signed-off-by: Paul R. Tagliamonte <paul@kittycad.io>
* Start to clean up Sentry now that the app is back up again.
Remove Sentry from local development I thought .env.development
was for dev.kc.io, not just local dev. Someone can add this to .local
if they need to test the Sentry stuff for now.
Signed-off-by: Paul Tagliamonte <paul@kittycad.io>
Collect WebRTC Statistical Information
Add in some instrumentation to track the duration of the setup phase,
and set up a job to make periodic use of the WebRTC Statistics API
to collect information about the connection (specifically, each track),
including transport-level information, timing information and bandwidth
information.
Sentry isn't the best place for that information, but it'll work until we
can work out a good long-term solution for it.
Signed-off-by: Paul Tagliamonte <paul@kittycad.io>
* Fix up message structure to match the new Engine messages
The types are still jacked up, I reckon we need to bump the node
@KittyCAD dep.
Signed-off-by: Paul Tagliamonte <paul@kittycad.io>
* update types
* fmt
* export tsc
* fmt again
---------
Signed-off-by: Paul Tagliamonte <paul@kittycad.io>
Co-authored-by: Kurt Hutten Irev-Dev <k.hutten@protonmail.ch>
In the future, this should be sent as telemetry, but at least this would
give us a bit of info about the latency sitatuion locally if we start
seeing the refresh happen a lot.
Signed-off-by: Paul Tagliamonte <paul@kittycad.io>
Because we gate a lot of things off this.foo?, leaving the closed
websocket/pc/etc in-place was causing a noisy log, and mucking with
reestablishing a broken connection.
While I was in here, I fixed a style nit from yarn.
Signed-off-by: Paul R. Tagliamonte <paul@kittycad.io>
* Build out EngineConnection's retry and timeout logic
* Migrate the EngineConnection to be an EventTarget for other parts of the
code (mostly the EngineManager, but maybe others?) to listen to, rather
than having a boolean 'done' promise, and remove callbacks in favor of
the eventListeners.
* When a WebRTC connection is online, send a 'ping' command every 10 seconds.
The UDP stream likely needs something similar, but the connection is
maintained by the WebRTC video stream for now.
* Begin to migrate code to use a more generic object "send" helper
which can handle the JSON encoding, as well as connection retry logic
in the future.
* Add a watchdog to trigger 5 seconds after a connection is initiated
to cancel and retry the connection if it's not become ready by the
time it wakes up. This won't watch an established connection yet.
Signed-off-by: Paul R. Tagliamonte <paul@kittycad.io>
The front-end and the back-end communicate with three channels. The
first is the WebSocket connection to the Engine API. Once that
connection is online, a WebRTC connection is negotiated, which contains
one video stream from the server to us for the GUI, and a second, which
is a binary data channel from us to the server, which we send JSON over
for real-time events like mouse positioning.
The lifecycle of the WebRTC connection and the WebSocket connection are
tied, since if the WebSocket connection breaks down, the WebRTC
connection must get restarted (to get a connection to the *same* backend
that we have an open WebSocket connection to).
This starts a move to split the WebRTC and WebSocket pair to be managed
by a new class (EngineConnection), which will only start and maintain
the WebSocket and WebRTC channels. Anything using the EngineConnection
will be able to communnicate commands without needing to add control
logic for the underlying data channels.
Signed-off-by: Paul R. Tagliamonte <paul@kittycad.io>
We can create a enginelessExecutor that can be used for many of the
executor tests that will be much more performant for tests that don't
need the engine to actually do any modeling work.
* Intital async of executor
The execture now sends websocket message instead of calling functions
directly from the engine, When it does so it holds onto the id.
The engine is still returning geo/polys directly but I'm working make it
so that the UI doesn't need to know about that, so that we can switch
over the streaming ui.
Things left to do:
- it is still making both direct function calls and websockets, and the former should be removed.
- It does highlighting of segments and sourceRanges not through websockets and that needs to be fixed.
- Tests have not been adjusted for these changes.
- Selecting the head of a segment is not working correctly again yet.
* Rough engine prep changes (#135)
* rough changes for engine prep
* mouse movements working again
* connect to engine for startsketch, line, close and extrude
