A poisoned message is a message leading to an error because of the message itself and not a database condition.

For instance, a message leading to a deadlock is not a poisoned message because it can complete with the next retry.

A message leading to a primary key violation will always fail, regardless of the number of retries (assuming there's no DELETE operation in between...).

To test such a scenario, find a message condition that'll pass your validation process (I hope, there's such a code section 😉 ) but will still fail, leading to a rollback of the code activated by the message.

Without knowing the tasks you trigger with a SSSB message it's hard to tell how to simulate a poisoned message...