--- schema_version: "1" id: 1e1d49b652b727dd5e46e32f54c3d57768943f4f707ab1d044d8b39db537d3e8 title: Troubleshooting a Failing DataWeave Script collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/dataweave/2.3/dataweave-troubleshoot.md canonical_url: https://docs.mulesoft.com/dataweave/2.3/dataweave-troubleshoot source_site: docs.mulesoft.com content_type: documentation content_hash: 46d1704fd506226a6dc955141fcb3c4358baf8faaa1e718a4946c049a30d8880 description: MuleSoft Documentation Site release: "2.3" latest: false --- --- product: DataWeave version: 2.3 keywords: studio, anypoint, esb, transform, transformer, format, aggregate, rename, split, filter convert, xml, json, csv, pojo, java object, metadata, dataweave, data weave, datamapper, dwl, dfl, dw, output structure, input structure, map, mapping --- # Troubleshooting a Failing DataWeave Script > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When you troubleshoot a failing script, one challenge to reproducing an error is having the same inputs the script had when it executed, especially in production environments where inputs can change unexpectedly. Therefore, it’s important to capture the inputs going into a script debugging or using loggers. Often, the failures occur because the input coming from another component upstream is not valid. You can find here a listing of the most common DataWeave errors and how to overcome them. ## Dump Input Context and the Script into a Folder In Mule 4.2.1, DataWeave introduced an experimental feature that enables you to dump the input context and the failing script into a folder so that you can track the failing script along with the data that makes the script fail. This tool is particularly useful for checking that received input data is valid because incorrect scripts often fail when an upstream component generates invalid data. To use this feature: 1. Set the following system property to enable the dump feature: `-M-Dcom.mulesoft.dw.dump_files=true` 2. \[Optional\] Specify the path in which to generate the dump files: `-M-Dcom.mulesoft.dw.dump_folder=` The default directory is `/tmp`. ## DataWeave Exceptions The following are some common DataWeave exceptions that you can find in your dump file, along with some details to troubleshoot these errors. ### Incorrect Arguments When a function is called with the incorrect kind of argument, it throws the exception, `org.mule.weave.v2.exception.UnsupportedTypeCoercionException`. Causes of this exception include: - [Function Does Not Accept Null Argument](#null_arg_not_accepted) - [MIME Type Is Not Set](#mimetype_unset) #### Function Does Not Accept Null Argument The most common cause of this exception occurs when one of the arguments is `Null` and the function does not accept `Null` as an argument. This issue results in an error message similar to the following: ```weave You called the function '++' with these arguments: 1: Null (null) 2: String (" A text") But it expects one of these combinations: (Array, Array) (Date, Time) (Date, LocalTime) (Date, TimeZone) (LocalDateTime, TimeZone) (LocalTime, Date) (LocalTime, TimeZone) (Object, Object) (String, String) (Time, Date) (TimeZone, LocalDateTime) (TimeZone, Date) (TimeZone, LocalTime) 1| payload.message ++ " A text" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Trace: at ++ (line: 1, column: 1) at main (line: 1, column: 17) ``` One way to resolve this issue uses the `default` operator. For example, using `payload.message default "" ++ " A text"` appends empty text when the message is null. #### MIME Type Is Not Set When the MIME type is not set, you receive an error message similar to the following: ```weave You called the function 'Value Selector' with these arguments: 1: String ("{ \"message\": 123}") 2: Name ("message") But it expects one of these combinations: (Array, Name) (Array, String) (Date, Name) (DateTime, Name) (LocalDateTime, Name) (LocalTime, Name) (Object, Name) (Object, String) (Period, Name) (Time, Name) 1| payload.message ^^^^^^^^^^^^^^^ Trace: at main (line: 1, column: 1) ``` When no MIME type is set on the payload, the MIME type defaults to `application/java`, and the content is handled as a `String` instead of a JSON object. ### Stack Overflow When a function recurses too deeply, an error like the following one is thrown: ```weave Stack Overflow. Max stack is 256 ``` You can configure the maximum stack size by using the property `com.mulesoft.dw.stacksize`. ## DataWeave Warnings The following are some common DataWeave warnings that you can find in your dump file, along with some details to address these warnings. ### End of Input Was Reached This warning shows because DataWeave treats the Unicode non-character `U+FFFF` as a special character that indicates the end of input. To avoid this warning, replace the special character in the raw payload and then proceed as usual. ```weave read(payload.^raw replace "\uFFFF" with "NonChar") ``` ## Output Mismatch When Undefined Unlike transformations, DataWeave expressions do not require you to define an output format because DataWeave can infer the output based on the expression and the variables you use. Occasionally, the inference process results in a mismatch between the inferred type and the expected type. To resolve this issue, you must make the output explicit. Common examples of this situation occur when: - [Extract Data from XML](#xml_extraction) - [Handle Multipart Entries](#multipart_handling) - [Manipulate Text Data](#manipulating_text) ### Extract Data from XML When extracting a String, for example, from an XML payload with the expression `payload.order.product.model`, DataWeave infers an XML output based on the payload format. In such cases, an error similar to the following one occurs: ```weave "Trying to output non-whitespace characters outside main element tree (in prolog or epilog), while writing Xml at ." evaluating expression: "payload.order.product.model". ``` For such an error, you must make the output format explicit, for example: `output text/plain --- payload.order.product.model`. ### Handle Multipart Entries A common inference error occurs with multipart data, which has a very specific structure. Consider a multipart payload and the expression `dw::core::Objects::keySet(payload.parts)`. Without an explicit output format, DataWeave must infer, based on the payload type, that you intend to output multipart content. In this case, an error similar to the following is thrown: ```weave "Expecting type is { preamble?: String, parts: { _*: { headers: Object, content: Any } } } but got Array, while writing MultiPart. Trace: at main (Unknown)" evaluating expression: "dw::core::Objects::keySet(payload.parts)". ``` To resolve this issue, you must define an output format, for example: `output application/json --- dw::core::Objects::keySet(payload.parts)` ### Manipulate Text Data You can use text data to create a more complex object. However, if you do not define the output format for the input text data, DataWeave infers that it must use the plain text writer for the output. The expression `payload splitBy ' '`, for example, will fail with an error similar to: ```weave "Text plain writer is unable to write Array. Reason: Cannot coerce Array (org.mule.weave.v2.model.values.ArrayValue$ArraySeqArrayValue@1331b353) to String Trace: at main (Unknown), while writing TextPlain. Trace: at main (Unknown)" evaluating expression: "payload splitBy ' '". ``` Making the output explicit solves the issue: `output application/java --- payload splitBy ' '` ## See Also - [Known Issues](https://help.salesforce.com/s/issues)