pnp
[Bug] Without the required scope errors returned from 'tenant people profilecardproperty' commands are vague
I don't have the required scope added yet to my app reg but the error returned is a bit vague:
That's probably because the error object coming in from the Graph has an empty message. :(
not sure how to solve this here... The MS Graph team should make this more descriptive, or we should implement checks based on the HTTP status code.. But that seems a change that would impact a lot of other code.
Originally posted by @martinlingstuyl in https://github.com/pnp/cli-microsoft365/issues/5624#issuecomment-1791486402
@wictorwilen, also one point on returning errors. I've seen multiple errors coming in (for example this one) that have an error code but no userfriendly error message. Something to pick up by the graph Team?
@martinlingstuyl since this is a bug on the API, shall we close this issue as it's nothing that we should fix ourselves?
I'm seeing teams meeting add command throws the same @waldekmastykarz, apparently this is a wider issue. Maybe it's not our bug, but it is very annoying to not know what is going on. Should we implement a fallback error that shows a general forbidden message if a 403 is returned from an endpoint and no error message is available?
If we know of specific exceptions, let's definitely aim to provide a clear(er) error message to help unblock users.
indeed this is a 'bit' tricky 🤔 I mean if the:
-
messageof the error response is empty - the error code is
UnknownError - all we have is the error date and request id's... so basically a date and two GUIDs 😅
then how should I give a better response to the user if the API error response does not give any kind of hint of what happened?
I mean the only thing we may show is instead of presenting Error [object Object]' show a message like hey something didn't work, but we also don't know what it is` 😜
indeed this is a 'bit' tricky 🤔 I mean if the:
messageof the error response is empty- the error code is
UnknownError- all we have is the error date and request id's... so basically a date and two GUIDs 😅
then how should I give a better response to the user if the API error response does not give any kind of hint of what happened? I mean the only thing we may show is instead of presenting
Error [object Object]' show a message likehey something didn't work, but we also don't know what it is` 😜
That's where our domain knowledge comes into play. Can we make an assumption about what could be wrong? Even if it's a few things, it would be helpful to give the user some hints about what they should examine to debug the issue.
Yes we may do that for sure but we still need to leave some 'unknown' point in the list of possibilities why something fails. Let's say we show an error message that probably you need to correct X Y or Z to have it running. Ok what if the user check the X the Y and the Z and everything it's fine and our command still doesn't work 🙂. Then the blame is a bit on us right 😅 but actually we also don't know for 100% and we just assume what might be wrong right 😉.
It'll be a matter of phrasing it correctly. A statement like: "we don't know what happened" is useless on its own. We could say something along the lines: an error has occurred. We suggest you check the following: .... While it's not a guarantee, it increases your chances of getting unblocked.
We could also change the message based on the HTTP status code. A 403 or 401 without message (like with teams meeting add) obviously should show a different message than a 400 would...
We could also change the message based on the HTTP status code. A 403 or 401 without message (like with
teams meeting add) obviously should show a different message than a 400 would...
We should definitely factor in the status code if we can infer some meaning from it.