Added error message and exposes WASM error message

[carrycooldude]

Reference to this issue: #131

Before sending a generic error, wws must print the Wasm backtrace in the terminal. The stderr is configurable, so the stderr_file (Option) may contain a file descriptor that should be used. If it's None, you can directly call eprintln! with the right message.

[vmwclabot]

@carrycooldude, you must sign our contributor license agreement before your changes are merged. Click here to sign the agreement. If you are a VMware employee, read this for further instruction.

[vmwclabot]

@carrycooldude, we have received your signed contributor license agreement. The review is usually completed within a week, but may take longer under certain circumstances. Another comment will be added to the pull request to notify you when the merge can proceed.

[Angelmmiguel]

Thank you very much for your contribution @carrycooldude!

I added some notes about managing the case when the stderr is configured to be printed in a specific file instead of the stderr descriptor from the running process 😄

[carrycooldude]

Can you tell me why this error is coming? @Angelmmiguel

[Angelmmiguel]

Can you tell me why this error is coming? @Angelmmiguel

In this case, the error is related to the stderr_file type. Since this variable comes from actix Data, the type is Data<Option<File>> instead of Option<File>. You can get a reference to the inner element by calling the stderr_file.get_ref() method. That will return an &Option<File> that you can use 😄.

Also, I see you're using expect to ensure the functions return an Ok variable. In this case, this will throw a panic and won't return any proper result to the users. To avoid it and returning an error page to the user, you can default to eprintln! in case any of these functions fail.

[carrycooldude]

Can you tell me why this error is coming? @Angelmmiguel

In this case, the error is related to the stderr_file type. Since this variable comes from actix Data, the type is Data<Option<File>> instead of Option<File>. You can get a reference to the inner element by calling the stderr_file.get_ref() method. That will return an &Option<File> that you can use smile.

Also, I see you're using expect to ensure the functions return an Ok variable. In this case, this will throw a panic and won't return any proper result to the users. To avoid it and returning an error page to the user, you can default to eprintln! in case any of these functions fail.

Did that too also ,

let (handler_result, handler_success) =
            match route
                .worker
                .run(&req, &body_str, store, vars, &*stderr_file.get_ref())
            {
                Ok(output) => (output, true),
                Err(error) => {
                    if let Some(&stderr_file) = stderr_file {
                        let mut stderr_file = stderr_file.try_clone().expect("Failed to clone stderr_file");
                        stderr_file.write_all(error.to_string().as_bytes()).expect("Failed to write error to stderr_file");
                    } else {
                        eprintln!("{}", error);
                    }
                    (WasmOutput::failed(), false)},
            };

also, try to change to eprintln!() but getting error on that @Angelmmiguel

[Angelmmiguel]

@carrycooldude in this case, I believe the issue is on the following line:

if let Some(&stderr_file) = stderr_file {

Here, it's expecting that stderr_file is an Option, while it's a Data<Option>. You can get the reference using the get_ref method:

if let Some(file) = stderr_file.get_ref() {

That file variable (I changed the name for clarity) should be an &File you can use for that. Regarding the usage of eprintln!, use it when there's an error in the other methods. Something like:

if let Ok(mut file) = file.try_clone() {
  // ...
} else {
  eprintln!("{error}");
}

I also noticed that you changed the run arguments above. The &* dereference and reference it again. I know the CI will complain about it, so you can revert those changes :)

[Angelmmiguel]

@carrycooldude thanks for the changes! I enabled the CI for this PR and it's failing due to some linting issues. You can fix them using cargo fmt. I also recommend you to run cargo clippy (how to install) as the CI also runs it.

[vmwclabot]

@carrycooldude, VMware has approved your signed contributor license agreement.

[carrycooldude]

hey @Angelmmiguel , As checks are cleared of this PR, can you merge this?

[Angelmmiguel]

Changes LGTM! Thank you very much for your contribution @carrycooldude 😄👏

[carrycooldude]

Thank You So Much for the support @Angelmmiguel , I will learn from you more 🙏
Let me know if I will do more issues like these