Deployment failure on fly.io
I was able to deploy yesterday using:
wasp deploy fly setup viamviz bos
wasp deploy fly create-db bos
wasp deploy fly deploy
18 Replies
Digging into it more, my guess is that Wasp's validate-env.mjs script is complaining about the Viam robotic frameworks Typescript.
Here is the content of the peer.ts file that Wasp appears to be complaining about:
Here is what I posted to Viam's discord:
It appears that the Wasp web framework that I'm using is rejecting Viam's typescript code. Specifically, Wasp's validate-env.mjs script is rejecting peer.ts. I've attached the log when attempting to push to fly.io and also Viam's peer.ts. I believe that the problem is on lines 47-54:
const description = new RTCSessionDescription(
JSON.parse(atob(event.data))
);
const offerCollision =
description.type === "offer" &&
(description || peerConnection.signalingState !== "stable");
ignoreOffer = !polite && offerCollision;
I think that the problem is that "description," which is not a boolean value, is in the expression that is being evaluated to offerCollision, so Typescript somehow believes that offerCollision may not be a boolean. The solution, I believe, is not to rely on Javascript's idiomatic use of a non-boolean in a boolean logic expression.
But if I am correct, is it really a good idea to do type checking on other libraries' code? This seems like something that could make uses external dependencies in Wasp pretty onerous
Also (again, if my understanding is correct), why is this type-checking only done when deploying using the CLI deployment command, and not when I run "wasp start"?
Wohooo @Chris Paliqaw, you just became a Waspeteer level 2!
I'll dig into the question tomorrow, it's kinda late in my timezone 😊
sure thing! Sleep is the greatest brain food
@Chris Paliqaw sorry for a bit slow response on this - we had our yearly retreat last couple of days so we ran a bit slow on checking the Discord, but we are back and running now!
Just to confirm -> you got it running at the end? What have you done to make it work compared to what you did at the start?
As for TS typechecking of external libaries -> I agree, it sounds like we shouldn't be doing that during building / deploying, but I will let @miho or @Filip shed more light on this as they are our TS gurus.
I've only been able to the app running on fly.io without the Viam libraries. I can run the Viam version only locally so far. I can try deploying on Railway to see if it's actually a fly.io issue
Oh ok, so you dropped the viam libary -> meaning you haven't solved the problem, right?
It doesn't sound like fly.io issue, I believe it is an issue on our side, probably exactly what you identified, at least it sounds like so at first glance. Let' see what @miho will say tomorrow since he knows TS really well + worked on relevant part of Wasp and we will take it from there!
ok, cool! I can continue work locally for now
@Chris Paliqaw would you mind sharing your repository with me, so I can run it locally and try to pin point the issue?
It might be an issue with the
tsc compiler trying to compile your code and then it stumbles upon the external code -> which breaks for some reason. That's weird and tsc doesn't touch those deps usually 🤷♂️GitHub
GitHub - ChrisPaliqaw/ViamViz: Visualize the current state of Viam ...
Visualize the current state of Viam robots. Contribute to ChrisPaliqaw/ViamViz development by creating an account on GitHub.
@miho I recently learned that there is a flag for
tsc where you can specify for it if it should also check external libraries or not -> you might already know that, but I am writing it here in case you don't.Good to know 👍 I'll report back soon
I'm gonna work on this today @Chris Paliqaw
Just an update on this: we are looking into ways of making
tsc less of an annoyance when deploying your app.
1. The issue that shows up when I try building your app for production -> it's normal Typescript behaviour. You imported something from the Viam SDK, and then Typescript went ahead and checked all of the related files (since you imported something, it had to).
2. We already have the skipLibCheck option enabled, but that doesn't prevent tsc from checking the code you imported from 3rd party libs. So that wasn't a solution 😢
3. Not using tsc to check the types -> that works, but we have to think about all the implications of that for a bit.
We'll do something to make this work for you (either drop the tsc check or make it optional somehow) - and release a new minor version of Wasp which you can then use 🙃great!
at the same, I'll notify Viam
Did you get an update from the SDK authors? 🙂
In the meantime, we made an issue for ourselves that we'll tackle soon (in the next sprint) to enable you to disable
tsc checks when deploying to production. https://github.com/wasp-lang/wasp/issues/1457GitHub
Making type checking of client optional when building for productio...
Since we are using Vite, our dev and production process differ a bit in how we handle Typescript. In development, we don't use tsc to type check the user's code and instead rely on user'...
I haven't gotten a reply on that issue yet. I may just try to fix to myself
Big thanks!