Add an option to continue processing on deserialization errors

[AnkurSinhaaa]

feat(dlq): add continue-on-unhandled-errors for deserialization handler

• Introduced new configuration dlq.deserialization-handler.continue-on-unhandled-errors
• When enabled, all unhandled deserialization exceptions are routed to DLQ and processing continues
• Preserves existing behavior by default (false)

Refactoring:

• Extracted logic into helper methods (shouldResume, buildKafkaError, serializeError, resumeWithDlqRecord)
• Removed duplication in DLQ response creation
• Improved readability and separation of concerns in handler

Tests:

• Added unit tests for new configuration (enabled/disabled scenarios)
• Ensured backward compatibility with existing tests

[loicgreffier]

@AnkurSinhaaa Here's my review with some minor code refactoring.

BTW I'm wondering if we should also add a property to resume without forwarding anything to DLQ. We might want to continue and simply drop the records sometimes.

[loicgreffier]

Remove this extra-line

[loicgreffier]

I think the final return logic in this handler could be simplified as follows:

boolean shouldResumeWithDlq = shouldResume(exception);
return shouldResumeWithDlq ? resumeWithDlqRecord(consumerRecord, value) : Response.fail();

If the continueOnUnhandledErrors verification is included in the shouldResume function (see my comment https://github.com/michelin/kstreamplify/pull/514/changes#r3086483677)

[AnkurSinhaaa]

Thanks for the suggestions @loicgreffier

I’ve moved continueOnUnhandledErrors into the shouldResume method and simplified the return logic:

return shouldResume(exception)
? resumeWithDlqRecord(...)
: Response.fail();

This centralizes the decision logic and removes duplication.

Also agreed on the idea of supporting a "drop without DLQ" mode — that would be a useful addition, But the question is DLQ usage ? My personal opinion is to keep traces of dropped records for monitoring and debugging. I suggest introducing it as a separate configuration (e.g. drop-on-error) in a follow-up issue and PR to keep this change focused if we end up to finalize that we don't need them in dlq.

[loicgreffier]

@AnkurSinhaaa

I suggest introducing it as a separate configuration

Agree, resume and send to DLQ should remain the default. A "resume and drop" behavior should be controlled by a separate property