[
https://issues.apache.org/jira/browse/CAMEL-25324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18124839#comment-18124839
]
Guillaume Nodet commented on CAMEL-25324:
-----------------------------------------
This issue is being investigated by a coding agent (on behalf of gnodet).
Multiple confirmed bugs identified in the current camel-dataweave module on
main across all three layers (DataWeaveLexer, DataWeaveParser,
DataWeaveConverter):
*Lexer gaps:* @, ?, $$ (double-dollar accumulator), $(...) string
interpolation, and .. (descendant selector) are either silently dropped or
wrongly tokenized.
*Parser gaps:* var/fun declarations above the --- line are silently skipped in
parseHeader(). Type-annotated function parameters (: Number) are mishandled.
The $/$$ shorthand in lambda bodies (e.g. map { id: $.id }) does not produce a
proper lambda AST node.
*Converter gaps:* emitStringLit() double-escapes already-escaped quotes.
emitMultiValueSelector() uses std.map which does not handle one-or-many XML
children correctly. groupBy keys are not stringified. mapObject/pluck are not
recognized as postfix operators.
No commits address CAMEL-25324. The fix will implement the straightforward
subset incrementally as suggested by the reporter.
_Note: This comment was generated by an AI coding agent and requires manual
verification._
> camel-dataweave - common DataWeave constructs are converted wrongly or dropped
> ------------------------------------------------------------------------------
>
> Key: CAMEL-25324
> URL: https://issues.apache.org/jira/browse/CAMEL-25324
> Project: Camel
> Issue Type: Bug
> Reporter: Claus Ibsen
> Assignee: Guillaume Nodet
> Priority: Major
>
> Each of these was run through a Camel route with camel-datasonnet (on main,
> 4.23.0-SNAPSHOT; the converter shipped in 4.22.0):
> ||DataWeave||Result||
> |{{payload.items map \{ id: $.id \}}}|runtime: "Wrong parameter type:
> expected Function, got object" (an object passed to std.map)|
> |{{payload.items filter ($.qty > 1)}}|route fails to start with a parse error
> in the generated code|
> |{{payload.items reduce ($$ + $.price)}}|route fails to start ({{function($,
> $)}})|
> |{{var rate = 0.08}} / {{fun ...}} above the {{---}} line|declaration
> dropped, so "Unknown variable rate"|
> |{{payload.Order.@id}}|{{@}} dropped, so {{body.Order.id}}: "Field does not
> exist: id" (should be {{body.Order\['@id'\]}})|
> |{{"Hello $(payload.name)"}}|*wrong output, no error*: the literal text
> {{Hello $(payload.name)}}|
> |{{payload.a?}}|becomes {{body.a}}, which fails instead of returning a
> boolean|
> |{{payload..name}}|becomes {{body.name}}: wrong output|
> |{{payload.items\[?($.qty > 1)\]}}|becomes an index with a function|
> |{{mapObject}}, {{pluck}}|broken output|
> |{{"say \"hi\""}}|the quote is escaped twice, so the route fails to start|
> |{{groupBy ((i) -> i.qty)}}|fails, because the group key is a number
> ("expected String, got number" in camel.libsonnet); DataWeave turns keys into
> strings|
> |{{payload.Order.Items.*Item}}|becomes {{std.map(function(x) x.Item,
> body.Order.Items)}}, mapping over the object instead of collecting all Item
> children (one or many)|
> |{{fun f(a: Number): Number = ...}}|type annotations are added to the
> parameter list|
> These are everyday DataWeave, so most real MuleSoft scripts hit at least one.
> Fix the straightforward ones first ($/$$ shorthand, var/fun above the
> {{---}}, @attr, $(...) interpolation, ?, escaping, groupBy keys as strings,
> .* with one-or-many, typed params). {{match}}, {{mapObject}}, {{pluck}},
> {{..}} and {{\[?()\]}} can come next. Each fix gets a case in the executed
> test set (see the related issue).
> _Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
