oscerd opened a new pull request, #2992:
URL: https://github.com/apache/camel-kamelets/pull/2992
Fixes #2941.
The issue suspected this might need a runtime fix in `apache/camel`. It does
not — the cause is in the Kamelet, and it is a two-character-shaped fix.
## Root cause
`aws-ddb-sink` declared an inbound data type **default**:
```yaml
dataTypes:
in:
default: json
types:
json:
format: "aws2-ddb:application-json"
```
Declaring a default input type makes Camel apply that transformation at the
`kamelet:source` boundary — **before any step in the template runs**. Verified
by logging the headers as the very first step of the template:
```
STEP-1 headers=[{CamelAwsDdbOperation=PutItem, CamelAwsDdbItem={...},
CamelAwsDdbReturnValues=ALL_OLD}]
```
The message is already transformed on arrival. Two consequences:
1. `setProperty operation` ran *after* the transformer had already resolved
the operation from the body alone and defaulted to `PutItem`. A log placed
between the two showed `${exchangeProperty.operation}` = `UpdateItem` while the
transform had already happened — which is why this looked so puzzling.
2. The transformer stamps `CamelAwsDdbOperation`, and in `Ddb2Producer` that
header **beats** the endpoint's `operation={{operation}}` parameter. So the
Kamelet's `operation` property could never take effect.
The in-template `transformDataType` step was dead code as a result —
`Ddb2JsonDataTypeTransformer` returns early once `CamelAwsDdbItem` or
`CamelAwsDdbKey` is present.
This also explains the reported workaround exactly: setting the exchange
property in the *calling* route works because it is on the exchange before the
boundary transformation.
## Fix
Drop only the `default:` key. The transformation then happens at the
existing `transformDataType` step, after the operation is set.
```diff
dataTypes:
in:
- default: json
types:
```
All the declared input-type documentation — schema, `CamelAwsDdbOperation` /
`CamelAwsDdbReturnValues` header docs, description — is preserved. I
deliberately did not remove the whole `dataTypes` block (which also works)
because that metadata is worth keeping.
## Verification
Probed each operation with `camel run`, swapping the terminal `aws2-ddb`
endpoint for a `log` so the resolved headers are visible:
| operation | headers produced | correct? |
|---|---|---|
| `PutItem` | `CamelAwsDdbItem` + `ALL_OLD` | ✅ |
| `DeleteItem` | `CamelAwsDdbKey` + `ALL_OLD` | ✅ |
| `UpdateItem` | `CamelAwsDdbKey` + `CamelAwsDdbUpdateValues` + `ALL_NEW` |
✅ |
Before the change `UpdateItem` produced the `PutItem` shape —
`CamelAwsDdbItem` + `ALL_OLD` — which is the reported bug.
**The itest workaround is removed.** `aws-ddb-sink-route.yaml` set the
`operation` exchange property in the calling route; that is deleted here, so
the test now exercises the Kamelet's own `operation` property rather than the
workaround. `AwsIT` passes end to end against DynamoDB:
```
Tests run: 15, Failures: 0, Errors: 0, Skipped: 0 -- in AwsIT
PASS awsDdb()[1] PASS awsDdb()[2] PASS awsDdb()[3] PASS
awsDdb()[4]
```
Run with `CITRUS_CAMEL_CLI_KAMELETS_LOCAL_DIR` pointed at this working tree,
since without #2987 the itests resolve the released catalog and would not have
exercised this change at all.
`script/validator` reports no errors and `mvn clean install` passes from the
repository root.
## Note for reviewers
Two other Kamelets declare `dataTypes` **and** carry an in-template
`transformDataType` — `aws-ddb-streams-source` and `google-sheets-sink`. That
combination is what produced this bug here. I have not touched them: a source's
`out` data type is a different code path and neither has a reported defect, so
they are worth a look separately rather than a speculative change in this PR.
---
_Claude Code on behalf of Andrea Cosentino_
--
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]
