oscerd commented on issue #2872:
URL:
https://github.com/apache/camel-kamelets/issues/2872#issuecomment-5475459943
Worked through this one. Two of the three TODOs are already done; the third
is not just an assertion fix, and correcting it uncovers a real problem. No PR
yet, because the honest fix is not a one-liner.
## Already done
**Migrated off LocalStack.** `citrus-application.properties` now runs Floci:
```properties
# Use Floci as the AWS emulator (drop-in replacement for LocalStack)
citrus.testcontainers.localstack.image.name=floci/floci
```
**All four tests are re-enabled.** No `.disabled` files remain under
`aws/ddb/` — `put-item`, `update-item`, `delete-item` and `source` are all
live, and they pass:
```
Tests run: 15, Failures: 0, Errors: 0, Skipped: 0 -- in AwsIT
PASS awsDdb()[1] PASS awsDdb()[2] PASS awsDdb()[3] PASS
awsDdb()[4]
```
(The `.disabled` files still in the tree are cassandra, redis, mqtt5 and
nats — unrelated to this issue.)
## The delete-item assertion is worse than "wrong"
The TODO is right that the assertion is broken. The test seeds an item
directly, verifies it is present, runs the Kamelet with `operation=DeleteItem`,
and then asserts:
```yaml
# Verify Kamelet sink
- createVariables:
variables:
- name: "aws.ddb.items"
value: "[[id:AttributeValue(N=${aws.ddb.item.id}), title:...,
year:...]]"
```
That is the **pre-delete** state. Because the surrounding `repeatOnError`
succeeds as soon as the assertion holds, it passes on the first attempt against
the item that has not been deleted yet, and never observes the delete at all.
It is a false green, not merely a wrong expectation.
For contrast, `update-item` gets this right — its final assertion expects
the *new* title and the added `directors` attribute, so it genuinely verifies
the update.
## Correcting it exposes a functional failure
I changed the post-delete expectation to `[]` and ran `AwsIT` against Floci.
It fails:
```
Caught exception 'AWS DDB item verification failed' - performing retry #1
... through retry #20
Tests run: 15, Failures: 0, Errors: 1 -- in AwsIT
```
Twenty retries over roughly twenty seconds and the item is still there. No
DDB exception is logged in that window, and the seeded item verifies as present
immediately beforehand, so the run is healthy right up to the delete.
The Kamelet side looks correct. Probing `aws-ddb-sink` with `camel run`,
replacing the terminal endpoint with a log, `DeleteItem` produces exactly the
headers it should:
```
CamelAwsDdbKey={id=AttributeValue(N=1)}, CamelAwsDdbOperation=DeleteItem,
CamelAwsDdbReturnValues=ALL_OLD
```
and the body shape the test sends (`{"id": 3757}`, no `key` wrapper) is
handled correctly by the transformer — with no `key` node it treats the whole
body as the key.
So the remaining question is whether Floci actually honours `DeleteItem`
(this issue notes the original LocalStack failure was on exactly `UpdateItem`
and `DeleteItem`), or whether something in the producer path drops it. That
needs a direct `aws2-ddb` to Floci test with no Kamelet in between, which I
have not done.
## Why no PR
Fixing the assertion alone turns a passing test red without fixing the
behaviour, and leaving it as it stands keeps a test that cannot fail. Neither
is worth merging on its own, so I have left the tree untouched and am reporting
instead.
Suggested split, if that is agreeable:
1. determine whether Floci implements `DeleteItem` (direct `aws2-ddb` test,
no Kamelet)
2. depending on the answer, either fix the delete path or document the
emulator gap and skip the assertion explicitly rather than inverting it
3. then correct the assertion, so the test is green because the delete works
Happy to take step 1 if you want it pursued.
Related: #2941 is a genuine `aws-ddb-sink` operation bug I fixed in #2992 —
the inbound `dataTypes` default made the Kamelet's `operation` property
ineffective. It is not the cause here, since this test carries the workaround
that sets the operation exchange property in the calling route, but it is worth
landing before anyone re-tests this.
---
_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]
