P1 bug in wasp causing insanity in developer. Please isolate and fix. :-)
I just spent a day tracking down a problem, which manifests itself in a very unusual way,.
Adding this line of code (to a server-side .js file):
import { subtractCredits } from 'wasp/server/operations'
This causes relative imports to stop working, and you can't fix the build by fixing them (obvious now, not so a few hours ago). The broken import is the only error emitted during the build, so the tools leave you in a hole. Git archaeology FTW.
-------
In main.wasp we have defined subtractCredits as follows:
action subtractCredits {
fn: import { subtractCredits } from "@src/payment/creditManagement.js",
entities: [User]
}
and in src/payment/creditManagement.ts we have a "export const subtractCredits = async (args, context) => { ... }.
Not 100% certain what's wrong here. This code is server side as stated above. We call it successfully from client. This is the first time I tried to call it from server, and not only does it not work, it silently murders the build. 😦 [EDIT: Just saw the mismatch between .js and .ts in the import/actual filetype, unfortunately that was not the cause of the problem as the imports still break after fixing...]
29 Replies
Hi @Conspyre. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
I'm sorry to hear about the issue you're facing. Based on the information you've provided and the knowledge sources I have, it seems like there might be a misunderstanding in how to import actions on the server side.
In Wasp, when you're importing actions on the server, you should import them from
wasp/server/operations and not wasp/client/operations. This is because the server and client have different contexts and requirements. When calling an action/query imported from wasp/server/operations, you need to pass a context that contains the user info (without the entities). If your query doesn't require auth, you should be able to pass an empty object source (https://discord.com/channels/686873244791210014/1218567315185209464).
However, there seems to be an issue with the Wasp documentation that incorrectly states that you can import actions from wasp/client/operations on the server side. This is a mistake and the documentation needs to be updated source (https://github.com/wasp-lang/wasp/issues/1909).
As for the issue with relative imports stopping to work, it's hard to say without more information. There have been issues reported with inconsistent import extensions in both .wasp file and in JS files, which might be related to your problem source (https://github.com/wasp-lang/wasp/issues/1363).
I would recommend checking your import statements and ensuring that you're importing from the correct location (wasp/server/operations for server-side code). If the issue persists, it might be a good idea to report it on the Wasp GitHub issues page for further assistance.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?@kapa.ai in my read of the documentation, the docs correctly state to import from 'wasp/server/operations', and I am doing the same in my code. Believe you are hallucinating. Sorry my friend. 😦
The "broken relative imports" seems to be an internal bug, and some problem with my code may be triggering that bug, in my opinion, but I don't know. 😦
Will gather more data and report on Github.
Let me check the knowledge base for you. One moment! :books:
----------------------
I apologize for any confusion. If you're already importing from
wasp/server/operations as per the documentation and still encountering issues, it does seem like there might be a bug.
The issue with broken relative imports could be related to a known issue where the server requires extensions in imports, and there are even more considerations regarding if it is .js or .ts. This has been reported to cause confusion and could potentially be related to the problem you're experiencing source (https://github.com/wasp-lang/wasp/issues/1363).
Gathering more data and reporting the issue on the Wasp GitHub issues page is a good next step. The Wasp team is quite responsive and should be able to provide further assistance.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?Interesting re>that GitHub issue but it seems not to be relevant. If we remove that import / do not call that piece of code in that particular server function, the "relative import broken" issoe goes away entirely. Simply adding that one line - the import - is triggering the behavior. I just don't know how to distil this entire project down to a reproducible issue. @kapa.ai
Let me check the knowledge base for you. One moment! :books:
----------------------
I understand your concern. It's indeed strange that adding a single import line is causing such behavior.
Here are a few steps you could take to isolate the issue:
1. Check the imported module: Ensure that the
subtractCredits function in @src/payment/creditManagement.js doesn't have any issues or dependencies that could be causing the problem.
2. Simplify the function: Try to simplify the subtractCredits function to the bare minimum, removing any other imports or dependencies, and see if the issue persists.
3. Create a minimal reproducible example: If possible, try to create a new, minimal Wasp project where you only add similar action and try to import it in the same way. This could help you identify if the issue is specific to your current project or a more general issue with Wasp.
4. Check for updates or known issues: Ensure you're using the latest version of Wasp and check the Wasp GitHub issues page (https://github.com/wasp-lang/wasp/issues) for any similar reported problems.
If none of these steps help, I would recommend reporting this issue on the Wasp GitHub page with as much detail as possible. Even if you can't provide a minimal reproducible example, providing the details of your current setup, the exact error messages, and the steps you've taken to debug could be helpful for the Wasp team to investigate the issue.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?@kapa.ai I found the first user error, in the API declaration I had mistakenly put a .js extension for the file, which was itself a .ts file.
Correcting this error did not fix the issue. Uncommenting the import of this action breaks the build.
Are there any issues in the knowledge base or on Github regarding API actions and typescript files specifically?
Let me check the knowledge base for you. One moment! :books:
----------------------
Based on the knowledge sources provided, there are several issues related to TypeScript files in Wasp:
1. Issue #835 (https://github.com/wasp-lang/wasp/issues/835): This open issue discusses supporting custom TypeScript configuration in Wasp. It mentions that Wasp 0.12.0 shifted the goals for this issue, but the rest is still relevant.
2. Issue #910 (https://github.com/wasp-lang/wasp/issues/910): This closed issue discusses full-stack type support for Queries and Actions in Wasp. It mentions the goal of having users define everything about a Query or an Action once, probably inside the Wasp file.
3. Issue #589 (https://github.com/wasp-lang/wasp/issues/589): This closed issue discusses supporting user code written in TypeScript and TSX. It suggests finding a way to provide TypeScript support for user-defined code.
4. Issue #1430 (https://github.com/wasp-lang/wasp/issues/1430): This closed issue discusses figuring out Wasp's
tsconfig story for the restructuring. It mentions deciding on what to put in the user's TS config file, and how to reuse it in .wasp/out/server and .wasp/out/web-app.
5. Issue #1066 (https://github.com/wasp-lang/wasp/issues/1066): This closed issue discusses adding a TypeScript tutorial to Wasp's documentation.
While these issues provide some context about TypeScript support in Wasp, none of them seem to directly address the specific issue you're facing with importing an action from a TypeScript file. I would recommend reporting this issue on the Wasp GitHub page for further assistance.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?@kapa.ai update: I can change the import, pulling the function directly from the source file instead of from the wasp/server/operations wrapper, the build does not break, the birds resume singing, and the chemtrail fog clears from the skies. But we aren't using wasp actions framework any more. 😦
Let me check the knowledge base for you. One moment! :books:
----------------------
I understand your concern. Importing the function directly from the source file instead of from
wasp/server/operations does bypass the Wasp actions framework, which is not ideal.
The Wasp actions framework provides a structured way to handle server-side operations and ensures that the necessary context is passed to your actions. Bypassing it could lead to unexpected behavior or missing functionality.
Based on the knowledge sources, there's a discussion about this exact scenario on a Github issue (https://github.com/wasp-lang/wasp/issues/1909). It mentions that users can import actions directly from their files, but they have to construct the context completely on their own. If they import it via wasp/server/operations, they don't have to construct it completely on their own, but need to pass just user to the context and the rest will be added.
It's recommended to use the Wasp actions framework for server-side operations. If you're facing issues with it, it would be best to report this on the Wasp GitHub issues page for further assistance. The Wasp team is quite responsive and should be able to help you resolve the issue.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?@sodic another one for you for Monday
Yup thanks @Conspyre , our local expert for operation imports, @sodic , will give this a look 😄
Hey @Conspyre, I answered here: https://github.com/wasp-lang/wasp/issues/2271#issuecomment-2337775531
I'm guessnig that's you 🙂
TL;DR we need more info
GitHub
Adding an import from wasp/server/operations on server side code is...
Describe the bug This is kind of a weird problem. It's probably user error but it triggers a bug that breaks the build in a bad way. To Reproduce I added this exact line of code to my server si...
That was me. 🙂 TL;dr I suspect something dumb or rulebreaking vis a vis schema changes, but no longer can get back to that state. @sodic
Ok, so just to be clear, the problem is gone now?
@sodic Yes. The problem is gone if I import that Action directly. If I import it from "wasp/server/operations", it still breaks. Sorry if I wasn't more clear, still learning. 🙂
How bad of trouble am I getting into by going around the Wasp system to commit rather vital things to the database?
going around the Wasp system to commit rather vital things to the database?It's your app, you are free to do things directly of course. Just be careful around auth related tables, not to mess them up since Wasp expects them to look a certain way. Also, use Prisma schemas for everything to keep the migrations / Prisma Client working.
I think I'd prefer to use the Action, however something about that action causes the entire project to fall down if, in server code, I import that action from "wasp/server/operations". Doing so causes relative imports to fail and have to be converted to absolute path or something.
No no, I meant "does it work if you import it with
wasp/server/operations?" Can you change all your imports to import it from wasp/server/operations (and not directly)?
It definitely should be working with wasp/server/operations
If it isn't, can you reply to the questions I asked here here: https://github.com/wasp-lang/wasp/issues/2271#issuecomment-2337775531.
I need the error message you're getting, and ideally your project that reproduces the error.
I'd really like to solve this one 🙂Wasp version is 0.14.0. Other code is using 'wasp/server/operations' so it's not global in scope, but if I do this one import, we get a breaking build that has no useful info. I'd rather not share the entire project, but, I have wasted enough hours on this that I wouldn't mind helping you find this, as it's also a problem in my code 🙂
What steps would you take to debug this? It's in the "subtractCredits" method, and in main.wasp that's using a [User] entity, so, start whacking stuff off of that tree until it doesn't break, look for clues through a rough binary-search-of-whacking-code? 🙂 Other strategies welcome.
Side note: Currently debugging my docker deploy and why the expletive deleted it keeps redeploying the same old code over and over. If you have a good RTFM link, sure would appreciate it 🙂
Thanks! Let's start with the error message you get when it breaks. Can you share that?
Side note: Currently debugging my docker deploy and why the expletive deleted it keeps redeploying the same old code over and over. If you have a good RTFM link, sure would appreciate it 🙂Can you open a new thread for this? We'll sort it out there. Also, please add some more info (what's expletive, how exactly does it behave, code/screenshots, etc). But in a new thread 😄
All my Docker problems are non-wasp specific, firewalls and apache and other issues, and none of my changes for the last 10 build are running and I don't know who's holding the stale code. When I solve it I'll drop a deploying Wasp on Ubuntu guide 🙂
I took a look at this again, and I don't even know how to characterize it. When I switch the import back to wasp/server/operations, the build breaks in ways that don't give you information. Usually it's imports like "../foo" stop working, to fix them, make them "/here/is/foo" and you can spend all day fixing imports and you do not fix the problem. So sharing which import is breaking will not help. To be clear, if file A is where my import of this one goofy subtractCredits function is, file D will break and if you fix that then file G has an error, then P, Z, R, B, ... in no discernible pattern or rhyme or reason or any way that makes sense. 🙂
So what I'm looking for is a strategy. My theory is that one of my data structures is messed up in a way that triggers this. It's just a theory but testing it would lead me to cutting out all of the code in the project until I converge on what the issue is. Realistically that's probably the only way.
What would you do. You have 30K LOC on your desk and it's exhibiting this bizarre behavior. What do you do next?
I'll try that! I surely will 🙂
@Conspyre Can you please share the error message you get when the build breaks?
It might look like useless information, but it might mean something to me.
Text, a screenshot - anything will do
We are in "src/actions/transcribeVideo.js"
We have made this change:
import { HttpError } from 'wasp/server';
import { transcribeAudio } from '../server/whisperService.js';
import { handleOpenAIError } from '../inference/openaiErrorHandler.js';
//import { subtractCredits } from '../payment/creditManagement.ts'; <--- from
import { subtractCredits } from 'wasp/server/operations'; <--- to
Now, this breaks:
[ Server!] node:internal/errors:496
[ Server!] ErrorCaptureStackTrace(err);
[ Server!] ^
[ Server!]
[ Server!] Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/Users/walt/IdeaProjects/quillsense/app/.wasp/out/sdk/wasp/dist/ext-src/lib/utils' imported from /Users/walt/IdeaProjects/quillsense/app/.wasp/out/sdk/wasp/dist/ext-src/queries/getConversation.js
[ Server!] at node_internal_captureLargerStackTrace (node:internal/errors:496:5)
[ Server!] at new NodeError (node:internal/errors:405:5)
[ Server!] at finalizeResolution (node:internal/modules/esm/resolve:327:11)
[ Server!] at moduleResolve (node:internal/modules/esm/resolve:946:10)
[ Server!] at defaultResolve (node:internal/modules/esm/resolve:1132:11)
[ Server!] at nextResolve (node:internal/modules/esm/loader:163:28)
[ Server!] at ESMLoader.resolve (node:internal/modules/esm/loader:835:30)
[ Server!] at ESMLoader.getModuleJob (node:internal/modules/esm/loader:424:18)
[ Server!] at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:77:40)
[ Server!] at link (node:internal/modules/esm/module_job:76:36) {
[ Server!] code: 'ERR_MODULE_NOT_FOUND'
[ Server!] }
[ Server!]
[ Server!] Node.js v18.18.0
[ Server ] [nodemon] app crashed - waiting for file changes before starting...
Hopefully the node:internal/errors:496 means something
If we look at getConversation.js (has nothing to do with transcribeVideo.js, except that both of these things hang off of the User record), we find:
import { console_debug } from '../lib/utils';
Now this is interesting. I just tried a couple of non-working patterns like "@app/src/lib/utils" and put the original import back, and the compile error "jumped" to a new file:
[ Server!] node:internal/errors:496
[ Server!] ErrorCaptureStackTrace(err);
[ Server!] ^
[ Server!]
[ Server!] Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/Users/walt/IdeaProjects/quillsense/app/.wasp/out/sdk/wasp/dist/ext-src/server/wasabiService' imported from /Users/walt/IdeaProjects/quillsense/app/.wasp/out/sdk/wasp/dist/ext-src/actions/deleteImage.js
[ Server!] at node_internal_captureLargerStackTrace (node:internal/errors:496:5)
[ Server!] at new NodeError (node:internal/errors:405:5)
[ Server!] at finalizeResolution (node:internal/modules/esm/resolve:327:11)
[ Server!] at moduleResolve (node:internal/modules/esm/resolve:946:10)
[ Server!] at defaultResolve (node:internal/modules/esm/resolve:1132:11)
[ Server!] at nextResolve (node:internal/modules/esm/loader:163:28)
[ Server!] at ESMLoader.resolve (node:internal/modules/esm/loader:835:30)
[ Server!] at ESMLoader.getModuleJob (node:internal/modules/esm/loader:424:18)
[ Server!] at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:77:40)
[ Server!] at link (node:internal/modules/esm/module_job:76:36) {
[ Server!] code: 'ERR_MODULE_NOT_FOUND'
[ Server!] }
[ Server!]
[ Server!] Node.js v18.18.0
[ Server ] [nodemon] app crashed - waiting for file changes before starting...
And if we look at deleteImage.js, that is neither related to transcription nor is it related to conversations, we find:
// src/actions/deleteImage.js
import { HttpError } from 'wasp/server';
import { deleteFileFromWasabi } from '../server/wasabiService';
it's breaking on another relative import. We could play this all day, compiler is happy to serve new errors all day. 😕
So there are two clues. node:internal/errors:496 and that the relative import "failure" is transient.
LMK if I can get you more data.
Ok @kapa.ai I'm beginning to see that you don't understand deployment either. Let's not use Docker.
We're trying to start the node server directly, and it appears to live in the directory .wasp/out/bundle/server/server.js
I start the server with something like:
$ cd .wasp/out/server/bundle/
$ node -r dotenv/config server.js dotenv_config_path=../../../../.env.server
The server starts up and I am reverse proxying it with Apache, which is also serving the front end.
I can verify that the reverse proxy works by loading my test route at https://my.app/api/test-route and I can see its response. I can further verify this by stopping the node server, and confirming that my test route no longer loads.
However, if I go to the actual site at https://my.app/login where the front end is serving the login page, attempting to login gives a Request failed with status code 404 error in the browser. No console log is emitted from the terminal window where we have the server node process running.
Let me check the knowledge base for you. One moment! :books:
----------------------
I'm sorry to hear about the issues you're facing with your deployment. Based on the information you've provided and the knowledge sources I have, here are a few things you could check:
1. Environment Variables: Ensure that all necessary environment variables are correctly set up. This includes
DATABASE_URL, WASP_WEB_CLIENT_URL, WASP_SERVER_URL, and JWT_SECRET if you're using Wasp's auth features. The mechanism of setting these up is specific per provider source (https://wasp-lang.dev/docs/advanced/deployment/manually#environment-variables).
2. Server URL: Make sure that the WASP_SERVER_URL environment variable is set to the URL where the server is running. The server needs it to properly redirect users when logging in source (https://wasp-lang.dev/docs/advanced/deployment/manually#environment-variables).
3. Client URL: Ensure that the WASP_WEB_CLIENT_URL environment variable is set to the URL where your frontend app is running. The server needs to know about it to properly configure Same-Origin Policy (CORS) headers source (https://wasp-lang.dev/docs/advanced/deployment/manually#environment-variables).
4. Routes: Check your routes and ensure that they are correctly set up. The error "Request failed with status code 404" typically indicates that the requested resource could not be found on the server.
5. Logs: If there are no logs being emitted from the terminal window where the server node process is running, it could be that the server is not receiving the requests at all. This could be due to a misconfiguration in your reverse proxy setup.
If none of these steps help, it might be a good idea to report it on the Wasp GitHub issues page for further assistance. The Wasp team is quite responsive and should be able to provide further assistance.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?@kapa.ai it seemed the front end deployment script was missing WASP_WEB_CLIENT_URL. What is the complete list of environment vars which must be set on the client?
Let me check the knowledge base for you. One moment! :books:
----------------------
The environment variables that need to be set on the client side for a Wasp application are:
1.
REACT_APP_API_URL: This is the URL where your Wasp backend is running. It's used when creating the production build of your client application source (https://wasp-lang.dev/docs/advanced/deployment/manually#deploying-the-client).
2. WASP_WEB_CLIENT_URL: This is the URL where your frontend app is running. The server needs to know about it to properly configure Same-Origin Policy (CORS) headers source (https://wasp-lang.dev/docs/advanced/deployment/manually#environment-variables).
Please note that any other environment variables you want to use in your client code should be prefixed with REACT_APP_ source (https://wasp-lang.dev/docs/project/env-vars#client-env-vars).
Also, remember that client environment variables are embedded into the client code during the build and shipping process, making them public and readable by anyone. Therefore, you should never store secrets in them (such as secret API keys) source (https://wasp-lang.dev/docs/project/env-vars#client-env-vars).
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?@kapa.ai and the complete list of environment variables which must be set on the server side
Let me check the knowledge base for you. One moment! :books:
----------------------
The environment variables that need to be set on the server side for a Wasp application are:
1.
DATABASE_URL: This is the URL of the PostgreSQL database your app will use source (https://wasp-lang.dev/docs/advanced/deployment/manually#environment-variables).
2. WASP_WEB_CLIENT_URL: This is the URL where your frontend app is running. The server needs to know about it to properly configure Same-Origin Policy (CORS) headers source (https://wasp-lang.dev/docs/advanced/deployment/manually#environment-variables).
3. WASP_SERVER_URL: This is the URL where the server is running. The server needs it to properly redirect users when logging in with OAuth providers like Google or GitHub source (https://wasp-lang.dev/docs/advanced/deployment/manually#environment-variables).
4. JWT_SECRET: This is required if you're using Wasp's auth features. It should be set to a random string at least 32 characters long source (https://wasp-lang.dev/docs/advanced/deployment/manually#environment-variables).
5. PORT: This is the server's HTTP port number. This is where the server listens for requests. The default is 3001 source (https://wasp-lang.dev/docs/advanced/deployment/manually#environment-variables).
If your app is using an external authentication method(s) supported by Wasp (such as Google or GitHub), make sure to additionally set the necessary environment variables specifically required by these method(s). For Google, these are GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET source (https://wasp-lang.dev/docs/auth/social-auth/google#4-adding-environment-variables). For GitHub, these are GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET source (https://wasp-lang.dev/docs/auth/social-auth/github#4-adding-environment-variables). For Keycloak, these are KEYCLOAK_CLIENT_ID, KEYCLOAK_CLIENT_SECRET, and KEYCLOAK_REALM_URL source (https://wasp-lang.dev/docs/auth/social-auth/keycloak#4-adding-environment-variables).
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?Hey, sorry, @sodic I stopped to ask the bot some things in the wrong chat. Scroll up.