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
feat(index.ts): added late response handling with onLateResponse callback
- Introduced `allowLateResponseAfterTimeout` flag in `sendRequest` method to enable late response handling.
- Added `onLateResponse` callback in `sendRequest` method to handle late responses after request timeout.
- Modified `sendRequest` to store timed-out requests conditionally in `timedOutRequests` object.
- Updated response handler to invoke `onLateResponse` for late responses.
- Improved error handling by passing `CustomError` or response to the callback.
- Added detailed logging for late response handling.
- Updated README with documentation for late response handling and new error codes.
- Updated `auth-service` example to demonstrate late response handling in the README.
This feature allows users to handle late responses gracefully, providing better flexibility for real-time communication in microservices.
Copy file name to clipboardExpand all lines: README.md
+53-10Lines changed: 53 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -66,6 +66,7 @@ License: [MIT](./LICENSE)
66
66
- 🔗 Service discovery and registration (provided by the hub).
67
67
- 📡 Request routing and response handling (provided by the hub).
68
68
- ❤️ Heartbeat mechanism to detect and remove inactive services (provided by the hub).
69
+
- ⏳ Late response handling even after a request timeout.
69
70
70
71
<hr>
71
72
@@ -108,9 +109,14 @@ In this setup:
108
109
- Once connected, the **[Hub](https://github.com/arijitcodes/microstream-hub)** keeps track of all connected services, so you don’t need to manually configure connections between services. However, you still need to specify the target service and method when sending a request.
109
110
110
111
4.**Heartbeat Mechanism**:
112
+
111
113
- Services send regular "heartbeats" to the **[Hub](https://github.com/arijitcodes/microstream-hub)** to confirm they’re active.
112
114
- If a service stops sending heartbeats, the **[Hub](https://github.com/arijitcodes/microstream-hub)** removes it from the network.
113
115
116
+
5.**Late Response Handling**:
117
+
- If a request times out, you can optionally allow late responses to be handled via a callback.
118
+
- This is useful for scenarios where the target service may respond after the timeout period - and the request is for something that can be done in the background or processed later.
119
+
114
120
### ✨ Why Choose MicroStream?
115
121
116
122
**MicroStream** is designed to make microservice communication **simple**, **efficient**, and **scalable**. Here’s why you’ll love it:
@@ -121,6 +127,7 @@ In this setup:
121
127
-**Scalable**: Easily add more services without reconfiguring the network.
122
128
-**Lightweight**: Minimal overhead compared to traditional REST or gRPC.
123
129
-**Flexible**: Works seamlessly with any microservice architecture.
130
+
-**Late Response Handling**: Gracefully handle responses that arrive after a timeout.
-`handler`: The function to handle the request. It receives the request data and returns the response.
189
216
3.**Sending Requests**: The `sendRequest` method is used to send a request to another service. In this example, requests are sent to the "jwt-service" to generate a JWT and to the "profile-service" to fetch a profile by user ID.
190
-
-**Parameters**:
191
-
-`targetService`: The name of the target service.
192
-
-`event`: The event name to trigger on the target service.
193
-
-`data`: Optional data to send with the request.
194
-
-**Returns**: A promise that resolves with the response from the target service.
195
-
-**Error Handling**: The `sendRequest` method is wrapped in a try-catch block to handle any errors that may occur during the request. For example, if a request is sent to an invalid service, the [Hub](#microstream-hub-) will respond with an error, which will be received by the client and thrown accordingly. The catch block will catch the error, and the user can display it using the `error.message` property.
217
+
218
+
-**Parameters**:
219
+
220
+
-`targetService`: The name of the target service.
221
+
-`event`: The event name to trigger on the target service.
222
+
-`data`: Optional data to send with the request.
223
+
-`allowLateResponseAfterTimeout`: Whether to allow handling late responses after the request times out (default: `false`).
224
+
-`onLateResponse`: Optional callback to handle late responses. This callback is invoked if:
225
+
-`allowLateResponseAfterTimeout` is true, and
226
+
- A late response is received after the request has timed out.
227
+
228
+
-**Returns**: A promise that resolves with the response from the target service.
229
+
230
+
-**Error Handling**: The `sendRequest` method is wrapped in a try-catch block to handle any errors that may occur during the request. For example, if a request is sent to an invalid service, the [**Hub**](#microstream-hub-) will respond with an error, which will be received by the client and thrown accordingly. The catch block will catch the error, and the user can display it using the `error.message` property. For more error related info, please have a look at the [Error Structure](#error-structure-) or the [Error Handling Section](#error-handling-)
196
231
197
232
<hr>
198
233
@@ -279,11 +314,12 @@ try {
279
314
280
315
### Error Handling Best Practices 🎯
281
316
282
-
1. Always wrap requests in try-catch blocks
317
+
1. Always wrap requests in `try-catch` blocks
283
318
2. Check error codes for specific error handling
284
-
3. Use error.errorData for additional context in debugging
285
-
4. Handle REQUEST_TIMEOUT errors with appropriate retry logic
286
-
5. Implement proper logging for INTERNAL_SERVER_ERROR cases
319
+
3. Use `error.errorData` for additional context in debugging
320
+
4. Handle `REQUEST_TIMEOUT` errors with appropriate retry logic
321
+
5. Implement proper logging for `INTERNAL_SERVER_ERROR` cases
322
+
6. Use `allowLateResponseAfterTimeout` and `onLateResponse` to handle late responses gracefully
287
323
288
324
### Common Error Scenarios 🔄
289
325
@@ -306,10 +342,17 @@ try {
306
342
- Useful for debugging service-side issues
307
343
308
344
4.**Service Registration Errors**
345
+
309
346
- Occurs during initial connection
310
347
- Critical errors that may require process termination
311
348
- Check for duplicate service names in your network
312
349
350
+
5.**Late Response Errors**
351
+
352
+
- Occurs when a response is received after the request has timed out
353
+
- Includes the original request payload and response data
354
+
- Use `onLateResponse` to handle these scenarios gracefully
0 commit comments