albgen commented on issue #12434:
URL: https://github.com/apache/seatunnel/issues/12434#issuecomment-6043223738
Same root cause, but it also breaks the **HOCON** body, not only JSON —
adding a data point.
**Setup:** SeaTunnel 3.0.0 (Zeta, REST v2), `POST /submit-job?format=hocon`,
a SqlServer-CDC → Doris job whose `FieldMapper` renames a Microsoft Dynamics
365 Business Central system column:
```hocon
transform {
FieldMapper {
plugin_input = "bc_src"
plugin_output = "bc_mapped"
field_mapper = {
"$systemId" = "system_id"
"No_" = "no"
}
}
}
```
**Result on 3.0.0:**
```
{"status":"fail","message":"IllegalArgumentException: Failed to decrypt
config. Please check your configuration."}
ERROR [o.a.s.c.s.u.ConfigShadeUtils] - Failed to decrypt config with
identifier: default
ConfigException$BadPath: path parameter: Invalid path '$systemId': Token not
allowed in path expression: 's' ('$' not followed by {, 's' not allowed after
'$')
```
The same config runs on **2.3.13**. `ConfigShadeUtils.processConfig` already
rebuilt the config with `ConfigFactory.parseMap` there, but the 2.3.13 REST
submit path never called `decryptConfig`; in 3.0.0 it does on every submission
(`JobInfoService`), even with no `shade.identifier` set. So for REST users this
is a regression.
It affects anyone replicating Business Central: every BC table has a
`$systemId` column (newer BC versions add `$systemCreatedAt`,
`$systemModifiedAt`, …), so after upgrading to 3.0.0 every job that renames
them is rejected. Workaround for now: don't map the `$` columns.
From the review discussion, #12443's current head guards the `processConfig`
render → reparse round trip, which should cover this too. Could the PR add a
HOCON-body test with a `$`-prefixed FieldMapper key, and could the fix land in
3.0.1?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
