In rxjs what exactly does the observer.complete() do after observer.next() ?
From the documentation observer.complete notifies the Observer that the Observable has finished sending push-based notifications.
In the other hand, observer.complete it's a callback function and an Observable calls this method after it has called next() for the final time, if it has not encountered any errors.
In ReactiveX library, there are two types of messages.
First ones are ordinary messages. Ordinary messages are the ones sent with .next() and there can be 0-many of them.
Second type are notifications. These can be of two types - error and success. The error is sent with .error() and give some error details in it (like exception) and success is sent with .complete() meaning that there will intentionally be no messages. Every observable should end with a single error or a single success notification.
Related
I have a "ghost" express middleware, that is sometimes triggered to check stuff before a request gets answered. As it relies on some sort of reverse engineering, there's a high chance it encounters unhandled errors. I call it "ghost" precisely because it should NEVER end the request if it has an error.
Except I want these unhandled errors to be logged in Sentry, while at the same time passing the request to the next request handler. Is there any Sentry method that allows sending errors without throwing them?
For now, I simply log them with Winston at the "error" priority level, but I'm really trying to transition away from that with Sentry. Sentry contexts seem to be related with what I'm trying to do, but I didn't quite get what they are.
My bad, should have read the docs more carefully. https://docs.sentry.io/platforms/node/enriching-events/context/#passing-context-directly
I need to send notification mail if my lambda function gets any error or got timed out. I had handled errors programmatically in function code but unable to notify when function gets timed out.
I am ready with my SNS topic and all.
Can anyone please help regarding this.
Yes, You can provide SNS as the DLQ(Dead Letter Queue) Resource for your asynchronous Lambda functions (where the event sources are not stream based).
On failures like timeout, resource constraints,
endpoint access issues, the exception thrown by the lambda function will be sent to the configured DLQ.
Not sure on your use case, but you can check the time remaining, before the function times out using the context object getRemainingTimeInMillis function. Doing so would allow you to more gracefully handle timeouts than dropping to the DLQ for timeouts. Although, you could/should still put the DLQ in place for unexpected errors.
Is it possible that the onerror callback can be called where onclose will not be called immediately after? In other words, is it possible to get a WebSocket error which does not coincide with the connection then being closed?
If it is possible, I would like to test this case. I have a mocked backend which uses node.js and express-ws. What can I do in the backend to trigger the onerror event callback in the front end.
The error event will only ever be fired prior to then also firing the close event, at least by implementations that properly implement the specification, i.e. you will get error and close as a pair, or just close by itself.
The process for closing a websocket consists of 3 steps, the second of which optionally fires the error event if needed:
If the user agent was required to fail the WebSocket connection, or if the the WebSocket connection was closed after being flagged as full, fire a simple event named error at the WebSocket object. [WSP]
Before the third step then calls close:
Fire an event named close at the WebSocket object, using CloseEvent,...
And because both of these steps are one after the other inside the same queued task, your event handlers should be invoked one after the other, with no other events or tasks taking place in between them.
If I have a subscription inside an Tracker.autorun(), the publish takes a variable selector, means that every time, the return may vary, would minimongo cache all the docs returned from all the publications? or each time, it clears all its documents and only preserve the returned docs from previous publication?
Meteor is clever enough to keep track of the current document set that each client has for each publisher. When the publisher reruns, it knows to only send the difference between the sets. Let's use the following sequence as an example:
subscribe for posts: a,b,c
rerun the subscription for posts b,c,d
server sends a removed message for a and an added message for d.
Note this will not happen if you stopped the subscription prior to rerunning it.
I am using chrome.extension.onRequest.addListener, I see that I am calling sendResponse with no arguments (=> sendResponse(); ), Sometimes I get an error like this:
Error: Attempting to use a disconnected port object
Must I call sendResponse, or I can remove this function if I am not expecting to get a response from the background?
The documentation says:
Function to call (at most once) when you have a response.
This "at most once" sort of indicates that sending a response is optional. While I won't be able to get you an official confirmation, I checked the source code of my extension and there are several messages where sendResponse isn't being called - so far (after a year of heavy use) no issues.