Mule if flowVar used in Dataweave Transformer payl

I have an issue with a Mule Dataweave Transformer getting an error, this only occurs if :-

An enricher is present wrapping a json:json-to-object-transformer

 <enricher target="#[flowVars.myVar]" doc:name="Message Enricher"> 
    <json:json-to-object-transformer returnClass="java.util.HashMap" doc:name="JSON to Object"/>
</enricher>

A flowVar is involved in the Dataweave Transformer

The exception occurs on the 2nd dataweave :-

ERROR 2017-08-15 09:09:52,239 [amqpReceiver.02] org.mule.exception.RollbackMessagingExceptionStrategy: 
********************************************************************************
Message               : Exception while executing: 
{bar=1, foo=0}
 ^
Unexpected character 'b' at index 1 (line 1, position 2), expected '"'
Payload               : com.mulesoft.weave.reader.ByteArraySeekableStream@39e7a0d3
Element               : /subscribe-to-changeFlow4/processors/4 @ voa-009-mule-authorisation-search-api:test3.xml:58 (Transform Message)
Element XML           : <dw:transform-message doc:name="Transform Message">
                        <dw:input-payload mimeType="application/json"></dw:input-payload>
                        <dw:set-payload>%dw 1.0%output application/json---{field1: payload.foo,field2: payload.bar,field3: flowVars.myFlowVar}</dw:set-payload>
                        </dw:transform-message>
--------------------------------------------------------------------------------
Root Exception stack trace:
com.mulesoft.weave.reader.json.JsonReaderException: Unexpected character 'b' at index 1 (line 1, position 2), expected '"'
    at com.mulesoft.weave.reader.json.JsonTokenizer.fail(JsonTokenizer.scala:193)
    at com.mulesoft.weave.reader.json.JsonTokenizer.require(JsonTokenizer.scala:190)
    at com.mulesoft.weave.reader.json.JsonTokenizer.readString(JsonTokenizer.scala:74)
    at com.mulesoft.weave.reader.json.JsonTokenizer.readObjectMembers(JsonTokenizer.scala:146)
    at com.mulesoft.weave.reader.json.JsonTokenizer.com$mulesoft$weave$reader$json$JsonTokenizer$$readObject(JsonTokenizer.scala:140)
    at com.mulesoft.weave.reader.json.JsonTokenizer$$anonfun$readValue$1.apply$mcV$sp(JsonTokenizer.scala:37)

What happens is as soon as a flowVar is added into the 2nd data weave, then the payload seems to show as a Map rather than JSON.

The enricher with nested json-to-object-transformer is required to take a payload and allow the JSON to be accessed. If the enricher is removed it works fine
The seek(0) is required to reset the stream after the json-to-object-transformer as Answered in my last question
if the flowVar is removed from the 2nd dataweave it works fine

Test Case

  <flow name="subscribe-to-changeFlow4" processingStrategy="synchronous">

        <amqp:inbound-endpoint numberOfChannels="1" ref="authorisationChangeQueueDef4" responseTimeout="10000" doc:name="authorisation-change-consumer" />

        <dw:transform-message doc:name="Transform Message">
        <dw:set-payload>
<![CDATA[%dw 1.0
%output application/json
---
{
    foo:0,
    bar:1
}]]>
        </dw:set-payload>
    </dw:transform-message>

    <enricher target="#[flowVars.myVar]" doc:name="Message Enricher"> 
        <json:json-to-object-transformer returnClass="java.util.HashMap" doc:name="JSON to Object"/>
    </enricher>

    <expression-component doc:name="Expression">
        <![CDATA[payload.seek(0);]]>
    </expression-component>

    <set-variable variableName="myFlowVar" value="1234" doc:name="Variable" />

    <dw:transform-message doc:name="Transform Message">
        <dw:input-payload mimeType="application/json"/>
        <dw:set-payload>
<![CDATA[%dw 1.0
%output application/json
---
{   
    field1: payload.foo,
    field2: payload.bar,
    field3: flowVars.myFlowVar
}
]]> 
        </dw:set-payload>
    </dw:transform-message>

    <logger  level="INFO" message="#[message.payloadAs(java.lang.String)]" doc:name="Logger all "/>


    </flow>

回答1:

This is probably a bug in Mule and you can raise it in Mule jira

Which Mule runtime version are you using?

I tested locally and found this issue with Mule runtime 3.8.0 and Mule runtime 3.8.1: