fix(idempotency): is_missing_idempotency_key iterates dict keys instead of values

[Adityaj0]

Issue number: closes #8390

Summary

Changes

is_missing_idempotency_key iterated data directly for dict input:

if isinstance(data, (tuple, list, dict)):
    return all(x is None for x in data)

for x in data over a dict walks its keys, not its values. This is correct for list/tuple, but wrong for dict — a dict produced by a JMESPath multi-select expression (e.g. event_key_jmespath="{user: headers.user_id, order: body.order_id}") over fields that are all absent from the event resolves to {"user": None, "order": None}: ordinary non-None keys, all-None values. The key-based check incorrectly reports this as "not missing."

Consequence: with raise_on_no_idempotency_key=True, the safety check silently doesn't fire. With the default False, no warning is emitted and the all-None dict gets hashed into a real idempotency key, causing unrelated invocations that both fail to populate those fields to collapse onto the same key and get incorrectly deduplicated.

Fix: iterate data.values() for dict input.

if isinstance(data, dict):
    return all(x is None for x in data.values())
elif isinstance(data, (tuple, list)):
    return all(x is None for x in data)

Added is_missing_idempotency_key({"user": None, "order": None}) and is_missing_idempotency_key({"user": "abc"}) cases to the existing test_is_missing_idempotency_key in tests/functional/idempotency/_boto3/test_idempotency.py. The existing test only covered {None: None} (None as the key), which happens to still pass under the buggy key-iterating code — that's why it never caught this. Confirmed the new assertion fails against the pre-fix code and passes with the fix:

$ python -m pytest tests/functional/idempotency/_boto3/test_idempotency.py -q
108 passed

$ python -m pytest tests/functional/idempotency --ignore=tests/functional/idempotency/_redis -q
128 passed

(_redis excluded from my local run only because of an unrelated missing multiprocess dependency in my environment, not related to this change.)

User experience

Before: a dict-shaped idempotency key extraction (multi-select JMESPath) whose values are all missing is silently treated as present, either bypassing raise_on_no_idempotency_key entirely or generating a real (and collision-prone, since it's a constant hash) idempotency key from empty data.

After: correctly detected as missing, matching the existing behavior for list/tuple/scalar inputs.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud