Improve MR Error Messages (AZ935) #252
Conversation
it's ugly string-formatted versions of the data that's actually there, but it's better than nothing
AZ935 Before this patch, the error tuple would be passed to invoke_js, producing a function clause error in js_driver later. With this patch, the bad_encoding error is returned to the caller correctly.
much more descriptive, and in-line with what's happening underneath
|
I suppose some hints for triggering errors that render these messages might have been helpful… This one triggers an error in an erlang function if the given bucket/key does not exist: Triggering an error in JSON encoding, due to bad UTF8, takes two steps. First, upload a file of random, likely invalid-UTF8 bytes: Then run a JS map on it: |
Catching errors here hides failures from HTTP and PB clients. Removing the catch means that MR queries stop immediately on reduce failure, just like they do with map failures.
|
This small addition allowed all of this new error-returning stuff to work for reduce phases as well. Previously, when a reduce phase encountered an error, it would try reprocessing its inputs when it received more inputs. If the error still happened on the last input, the phase would end up passing its inputs onward as outputs, rather than raising the error to the user (https://issues.basho.com/show_bug.cgi?id=1185). The new behavior raises the error and fails immediately. |
the error should say "non_list_result"
to catch bad_json as well, and to avoid a 'bad_return_value' being sent to the client, instead of the real error
|
Pulled, ran. tested, played the az935 game, read, understood, +1'd |
PB error message is now a JSON object
|
Pulled the latest, ran, read, +1ing |
|
How to solve "bad_utf8_character_code" error returned by Riak MR? |
|
@tovbinm Javascript phases require that all inputs to them be valid UTF8. For map phases, this means that the value stored in your Riak object, as well as its bucket and key, must be valid UTF8. If you're getting a |
|
Got it. What about "application/binary" values? Why do I get the same error even in case when my map function is simple like this "function map () { return [1]; }" ? |
|
Could we please move this discussion to the mailing list? There are more people watching, ready to help, and interested in the discussion there. |
|
Sure. Thanks for your help! |
This PR "improves" MapReduce error messages.
At the moment, "improves" means, "gets more information out in the HTTP response." I'm interested in feedback about whether or not this is the right information to expose, and whether or not it's exposed in a useful format. If both aspects are +1, similar changes should also be made to the PB response.
Side note: There was early discussion about translating errors like
bad_encodingto more verbose English like "The input contained bytes that were not valid UTF-8 characters." This was dropped in favor of just changing the error atom tobad_utf8_character_codeto keep things simpler. The new atom should be descriptive, yet unique enough to describe further in other Google-reachable contexts, like the wiki.