W
Wasp•4w ago
mgp25

Configure timeout/exceptions for actions

Wasp version: 0.13.x So I have this situation where an action takes so much time that the connection closes because what I believe a timeout, and that is completely fine for me, however I would be able to properly control those exceptions when calling an action fails for whatever reason. Is there any way to do this? Right now I am getting the message Network Error. While this might work: 
catch (err: any) {
        if (err.message === "Network Error"){
catch (err: any) {
        if (err.message === "Network Error"){
It is not a proper solution, since there are many different causes of a Network Error. Thank you
3 Replies
kapa.ai
kapa.ai•4w ago
Hi @mgp25. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- Based on the knowledge sources provided, I can offer some insights on handling errors and timeouts for actions in Wasp. Here's what you can do: 1. Custom Error Handling: Wasp allows you to throw custom HttpErrors in your action implementations. This gives you more control over the error information sent to the client. Here's an example: 
import { HttpError } from 'wasp/server'  

export const createTask = async (args, context) => {  
 throw new HttpError(
   403, // status code  
   "You can't do this!", // message  
   { foo: 'bar' } // data  
 )  
}  
import { HttpError } from 'wasp/server'  

export const createTask = async (args, context) => {  
 throw new HttpError(
   403, // status code  
   "You can't do this!", // message  
   { foo: 'bar' } // data  
 )  
}
This approach is described in the Actions Error Handling documentation. 2. Timeout Handling: Unfortunately, the provided knowledge sources don't contain specific information about configuring timeouts for actions. The "Network Error" you're experiencing might be due to a server-side timeout, but we don't have enough information to confirm this. 3. Error Catching: Your current approach of catching the "Network Error" message is not ideal, as you've correctly pointed out. The error message "Network Error" can indeed be caused by various issues, not just timeouts. 4. Potential Improvements: While not directly addressing your specific question, there are ongoing efforts to improve error handling in Wasp. For instance, there's an open GitHub issue about improving how Fly deployment via Wasp CLI handles errors, which might lead to better error reporting in the future. Given the limitations of the current information, I would recommend the following: 1. Use the custom HttpError approach for errors you can anticipate and handle on the server-side. 2. For client-side error handling, consider implementing a more robust error checking mechanism that doesn't rely solely on the "Network Error" message. 3. If you need more specific timeout control, you might need to implement it at the application level, possibly using a library like Axios for your API calls, which allows for more granular timeout configuration. For the most up-to-date and specific advice on handling timeouts and exceptions in actions, I recommend reaching out to the Wasp community on their Discord channel or opening an issue on the Wasp GitHub repository. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @mgp25, 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?
miho
miho•4w ago
Maybe use axios.isAxiosError on the error and then you could have access to extra fields on the error besides the message? e.g. error.response.status or smth like that.
mgp25
mgp25OP•4w ago
I will look into this, and provide some feedback. Thanks!

Did you find this page helpful?