Runtime error in a pipeline function is not apparent when running mutation

[schickling]

Issue by FredyC Thursday Aug 17, 2017 at 14:52 GMT Originally opened as https://github.com/graphcool/api-bugs/issues/235

---

What is the current behavior? Running just a regular mutation over a type while there is a request pipeline which contains an error ends up with an error message from which it's not apparent where the problem is...

A function returned an unhandled error. Please check the logs for executionId 'eu-west-1:simple:cj6gh8qnshfmj0146nep4r84d

Please share the relevant part of your GraphQL schema and all functions, permissions or other project settings for easier reproduction

Setup a simple request pipeline function with a runtime error that runs with mutation, eg. createUser.

What is the expected behavior? For starters, it would be nice if error message included the name of the function which failed. To me, this error message wasn't clear that it's actually my custom function failing there (I completely forgot I have it there).

Furthermore, the error message tells you to check the logs for executionId while it's not possible to really find log message by that ID anywhere, not even mentioning a case when there multiple different functions that could be causing a problem.

For a stretch goal, it would be lovely seeing an actual error message from function run in the response payload.

[sorenbs]

Thanks @FredyC

Thee are several topics here

• [ ] Returning the function name is not desired as it is internal to your system, and you might not want to expose it.

• [ ] We should improve the error message to make it clear that it is a custom function that failed.

• [ ] We should make it possible to search across all logs (by id or message)

• [ ] The executionId is eu-west-1:simple:cj6gh8qnshfmj0146nep4r84d but should just be cj6gh8qnshfmj0146nep4r84d

[danielkcz]

Ok. Just to the first point, I meant the name of my function, not your internal function :) But if it would be possible to search through all logs by ID (from all functions) then it doesn't matter that much. Ideally, if that ID could be just clickable in error message to take me to logs with filtered ID.

[sorenbs]

A link to the log is a great idea.

I was actually referring to your function :-) These errors will be displayed to your users, and you might not want them to see your function names

[danielkcz]

Well, that would be only in case I would blindly show errors that server sends. Not very likely :) User will see there was an error and actual error is sent to Sentry for example.

Either way, I wouldn't consider function name to be a security risk. What can you do with it? :)

[kbrandwijk]

@FredyC Well, if your function is named 'secretlySendAllUserActivityToCompanyX' then you might have an issue... :smile:

[marktani]

Well, that would be only in case I would blindly show errors that server sends.

No, the client can inspect the actual network request containing the raw error message.

[kbrandwijk]

Not only that, your GraphQL endpoint could always be called directly, and the error would be returned without any additional client-side handling.

[danielkcz]

@kbrandwijk I guess that if someone names his function like that, then it's obvious begging for "hack it" :D

I am not a security expert, but I cannot see any harm in knowing a name of a regular function. Besides, there is a lot various names representing application logic within a schema. How can one function name (which you cannot access or see source code) do any harm?

[marktani]

I think we've nitpicked enough at this point 😄 We all agree that working with function logs should be a great experience, and it's not at the moment, so let's focus on improving it 🙂

[kbrandwijk]

@FredyC Talk to my penetration testing agency. Any information about the internal logic leaking out is bad. Logging it :+1: . Returning it in the response, :-1:

[marktani]

This issue has been moved to graphcool/graphcool-framework.