goutamadwant opened a new issue, #12083:
URL: https://github.com/apache/seatunnel/issues/12083
## Search before asking
- [x] I searched the issue and pull-request history using `AmazonSqs`,
`AmazonSqsConnectorException`, `AmazonSqs-01`, `json deserialization`, and
`ignore_parse_errors`. I found no open issue or pull request that addresses
this behavior.
## What happened
`AmazonSqsDeserializer` reports checked deserialization failures with
`AmazonSqsConnectorException` and the connector-specific `AmazonSqs-01` error
code. However, the JSON format converts malformed payload failures to
`SeaTunnelRuntimeException` with the common `COMMON-02` error code.
The Amazon SQS adapter currently catches only `IOException`, so this JSON
exception bypasses the connector error boundary and is exposed directly to the
operator.
This does not reintroduce the message-loss problem fixed by #12038: the poll
still fails before collection or deletion, so the SQS message remains available
for retry or its dead-letter queue policy. The problem is inconsistent
diagnostics. The same connector operation reports different top-level error
types and codes depending on how the configured format represents a parse
failure.
Expected behavior:
- A malformed JSON message fails with `AmazonSqsConnectorException` and
`AmazonSqs-01` when `ignore_parse_errors = false`.
- The original `COMMON-02` exception remains available as the cause.
- The message is not emitted or deleted.
- Non-JSON runtime failures are not mislabeled as parse errors or swallowed.
## SeaTunnel Version
Current `dev` branch. Reproduced on commits `1e450e11f` and `98182ca59`.
## SeaTunnel Config
```conf
source {
AmazonSqs {
url = "https://sqs.us-east-1.amazonaws.com/123456789012/orders";
region = "us-east-1"
format = "json"
delete_message = true
ignore_parse_errors = false
schema = {
fields = {
value = string
}
}
}
}
```
The reproduction uses an in-memory `SqsClient` test boundary with a message
body of `invalid`, so it does not require AWS credentials or network access.
## Running Command
```shell
./mvnw -pl seatunnel-connectors-v2/connector-amazonsqs
-Dtest='AmazonSqsSourceReaderTest#shouldWrapJsonParseErrorCreatedByFactory' test
```
## Error Exception
```log
Unexpected exception type thrown,
expected: AmazonSqsConnectorException
but was: SeaTunnelRuntimeException
Caused by: SeaTunnelRuntimeException:
ErrorCode:[COMMON-02], ErrorDescription:[Common JSON convert/parse 'invalid'
operation failed.]
```
## Proposed fix
Catch only `SeaTunnelRuntimeException` instances carrying
`CommonErrorCode.JSON_OPERATION_FAILED` at the Amazon SQS
schema-deserialization boundary. Wrap them with `AmazonSqsConnectorException`
and `AmazonSqs-01`, preserving the original exception as the cause.
Keep null-result handling outside that catch boundary to avoid double
wrapping. Do not catch arbitrary runtime exceptions, and do not extend the
boundary around downstream `Collector.collect` calls.
## Zeta or Flink or Spark Version
Engine-independent source-reader path.
## Java or Scala Version
Reproduced on Java 8 and Java 11. The proposed regression suite passes on
both Java versions.
## Are you willing to submit PR?
- [x] Yes, I am willing to submit a PR.
## Code of Conduct
- [x] I agree to follow this project's Code of Conduct.
--
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]
