docs(microservices): kafka retriable exceptions update

Author: kamilmysliwiec

content/microservices/kafka.md

@@ -349,7 +349,7 @@ If your handler involves a slow processing time for each received message you sh
 @MessagePattern('hero.kill.dragon')
 async killDragon(@Payload() message: KillDragonMessage, @Ctx() context: KafkaContext) {
   const heartbeat = context.getHeartbeat();
-  
+
   // Do some slow processing
   await doWorkPart1();
 
@@ -417,6 +417,8 @@ onModuleInit() {
 
 Similar to other transporters, all unhandled exceptions are automatically wrapped into an `RpcException` and converted to a "user-friendly" format. However, there are edge-cases when you might want to bypass this mechanism and let exceptions be consumed by the `kafkajs` driver instead. Throwing an exception when processing a message instructs `kafkajs` to **retry** it (redeliver it) which means that even though the message (or event) handler was triggered, the offset won't be committed to Kafka.
 
+> warning **Warning** For event handlers (event-based communication), all unhandled exceptions are considered **retriable exceptions** by default.
+
 For this, you can use a dedicated class called `KafkaRetriableException`, as follows:
 
 ```typescript

content/migration.md

@@ -79,6 +79,10 @@ killDragon(@Payload() message: KillDragonMessage, @Ctx() context: KafkaContext)
 }
 ```
 
+#### Kafka retriable errors
+
+In v9, we introduced the **[Retriable exceptions](/microservices/kafka#retriable-exceptions)** feature. Note: for event handlers (**event-based communication**) all unhandled exceptions become "retriable exceptions" by default, and so they will be auto-delivered.
+
 #### Fastify
 
 Fastify has been upgraded to v4. Also, all of the core Fastify plugins that were prefixed with `fastify-` are now renamed and published under the `@fastify` scope (for example, `fastify-cookie` becomes `@fastify/cookie`, `fastify-helmet` becomes `@fastify/helmet`, etc.). Read more [here](https://github.com/fastify/fastify/issues/3856).