Update tests after jettison lib change

[echarrod]

#41 has introduced some test failured after the jettison library change

The failure is caused by the dead letter consumer not being able to record an error, which leads to the original error being returned and the test failing. This is visible in the logs:

dead letter consumer cannot record an error: consumer error
at rpatterns/deadletter.go:65
at rpatterns/deadletter_test.go:139

The relevant code in rpatterns/deadletter.go shows that when the error cannot be recorded (i.e., the inserter returns an error), the consumer returns the original error instead of swallowing it:

64| } else if iErr := d.inserter(ctx, ev.ID, d.name, err.Error()); iErr != nil {
65|     log.Error(ctx, errors.Wrap(err, "dead letter consumer cannot record an error"),
66|         j.MKS{"consumer": d.name, "eventID": ev.ID, "errMsg": err.Error(), "recErrMsg": iErr.Error()})
67|     return err
68| }

The associated test case in rpatterns/deadletter_test.go expects this behaviour:

72|     expErr:         []error{consumerErr, consumerErr, consumerErr},

However, the logs indicate that this error scenario is occurring repeatedly, which suggests either:

• The inserter function used in tests (or in production) is returning an error (deadLetterErr) when it should not, or
• The test is set up to simulate a recording failure, but the code is not handling this as expected.

Solution:

1. Ensure that the error inserter function (the eFn passed to NewDeadLetterConsumer) does not return an error unless we are explicitly testing the failure path.
2. If we are testing the failure path, verify that the test expects the consumer to return the original error, as in the "0 retries 1 error failed to write" or similar test cases.

If we want to make the consumer ignore inserter errors and continue (not recommended unless we can safely drop error records), we could change:

67|     return err

to:

67|     return nil

But be aware this would change the intended semantics and could hide real operational issues.

Recommended action:
Check the implementation of the error inserter. If it is intentionally returning errors, adjust the test expectations. If not, ensure it behaves as expected in normal operation.

For reference, here is the relevant file: rpatterns/deadletter.go@e240053.