You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
2. Register the handler in the `src/shared/modules/kafka/handlers/registered-handlers.config.ts` config handlers array.
113
-
3. The handler will automatically be registered and start consuming messages.
112
+
2. Add the handler to
113
+
`src/shared/modules/kafka/handlers/registered-handlers.config.ts` so the
114
+
handler catalog remains complete.
115
+
3. Add the handler class to `GlobalProvidersModule.providers`. Nest must
116
+
instantiate the provider for its `onModuleInit` registration to run.
117
+
4. The registered topic is included when the Kafka consumer starts.
114
118
115
119
### Dead Letter Queue (DLQ) Support
116
120
@@ -127,9 +131,13 @@ The application includes a robust Dead Letter Queue implementation for handling
127
131
128
132
2.**Retry Mechanism**:
129
133
130
-
- Failed messages are automatically retried up to the configured maximum number of retries
134
+
- Failed messages are automatically retried up to the configured maximum
135
+
number of retries, whether or not DLQ publication is enabled
131
136
- Retry count is tracked per message using a unique key based on topic, partition, and offset
132
137
- Exponential backoff is applied between retries
138
+
-`KAFKA_DLQ_ENABLED` controls whether an event is copied to a DLQ after the
139
+
retry budget is exhausted; exhausted messages are logged and committed
140
+
when DLQ publication is disabled
133
141
134
142
3.**DLQ Processing**:
135
143
@@ -156,6 +164,12 @@ The application includes a robust Dead Letter Queue implementation for handling
156
164
157
165
- The service uses `@platformatic/kafka` 2.8.0 for broker failover and consumer group recovery fixes.
158
166
- Platformatic Kafka 2.x raises the aggregate consumer Fetch limit to 50 MiB. The service deliberately retains the previous 10 MiB `maxBytes` limit to avoid increasing its per-consumer memory envelope.
167
+
- Streams use committed-offset mode so restarts resume the consumer group's
168
+
last successful offset. A topic without a committed offset starts at latest,
169
+
which avoids replaying historical events when a handler is first deployed.
170
+
- Submission confirmation additionally persists a request in the same database
171
+
operation as each normal member submission. Its scheduled recovery pass does
172
+
not depend on Kafka redelivery, so a missed source event remains recoverable.
159
173
- Terminal consumer or producer client errors and offset commit timeouts mark Kafka health as `reconnecting` and start the shared reconnect lifecycle. A successful reconnect returns health to `ready`; exhausted attempts mark it as `failed` with the last failure reason.
0 commit comments