Add a condition for the object type error

[samuelcarreira-ibs]

When a real usage scenario I saw that lot of API DML and Apex errors are returned as an object. So, if the user wants to know more details about the error we need to add the following line:

if (error.body && typeof error.body.message === "object") {
  return error.body.message.map((e) => e.message);
}

Instead of just showing the generic server error 500, it can show something like 'X' field is invalid

My proposal is to change the reduceErrors function to something like

...
// UI API DML, Apex and network errors
else if (error.body && typeof error.body.message === "string") {
  return error.body.message;
}
// UI API DML, Apex and network errors but with object response
else if (error.body && typeof error.body.message === "object") {
  return error.body.message.map((e) => e.message);
}
// JS errors
else if (typeof error.message === "string") {
  return error.message;
}
...

https://github.com/trailheadapps/lwc-recipes/blob/d0c76376dc1954a73910c543c495964f05dfa3f9/force-app/main/default/lwc/ldsUtils/ldsUtils.js

[github-actions]

Welcome! 👋

Thank you for posting this issue. 🙇🏼‍♂️ We will come back to you latest within the next 48h (working days). Stay tuned!

[Peter Chittum]

Thanks. I'll take a look at this. Can you expand a bit on which specific use cases, or provide some code in a gist I can test out?

I'm asking for more direction because I was just investigating #445 and discovered that the Apex errors when handled by LWCs hosted from an org were returning the correct messages. However when hosted in the local LWC server (in development only) there are quite a few instances where you don't get the correct error message.

Can you please verify for me that the behavior you're seeing is LWCs when deployed to the org, rather than in local server?

Also, if you can provide some specific Apex exception types to test, that will also help.

I'm just about to raise a case to the local server repo, in fact, so that there is error surfacing parity between an org, and local server.

Thanks!

[github-actions]

Flagging this as stale, as there was no recent activity within the last 14 days. 🧐

[samuelcarreira-ibs]

Hi @pchittum , sorry for the delay in the response. You are right, the absence of the detailed error message only occurs on local dev server.

Sample apex

@AuraEnabled(cacheable=true)
    public static Account getSingleAccount(Id recordId) {
        return [
            SELECT Id, Name
            FROM Account
            WHERE Id = :recordId
            WITH SECURITY_ENFORCED
            LIMIT 1
        ];
    }

Sample JS that should return an error (invalid parameters)

 const data = await getSingleAccount();

Output on local

Server Error

console.error

{"status":500,"body":{"message":[{"exceptionType":"System.QueryException","isUserDefinedException":false,"message":"List has no rows for assignment to SObject","stackTrace":"Class.XgetSingleAccount: line 4, column 1"}]},"headers":{}}

Output on scratch org

List has no rows for assignment to SObject

console.error

{"status":500,"body":{"exceptionType":"System.QueryException","isUserDefinedException":false,"message":"List has no rows for assignment to SObject","stackTrace":"Class.TreeView.getSingleAccount: line 4, column 1"},"headers":{}}

So the code proposal here just makes sense if you want to show the detailed errors on local dev environment (at least until the error surfacing parity between an org and local server being solved)

Thank you for the attention

[Peter Chittum]

Thanks @samuelcarreira-ibs.

We've decided that we're not going to take action on changing the ldsUtils component based on what is essentially a bug in the local development server environment. An issue has been opened on the local dev server repo, which you can use to track the status of this behavior.

But in any case, thanks very much for bringing this to our attention.