I'm having trouble understanding when bluebird will log an unhandled rejection versus dropping it. I guess this has something to do with what the documentation calls "the second turn" but I'm not clear what that means.
Promise.reject(new Error("oops"))
-> no log
Promise.reject(new Error("oops")).then(function() {})
-> stack trace logged
Promise.method(function() { throw new Error("oops"); })()
-> no log
Promise.method(function() { throw new Error("oops"); })().then(function() {})
-> stack trace logged
Promise.promisify(function(k) { k(new Error("oops"), null); })()
-> stack trace logged
I am in the middle of converting some code to bluebird promises and I am getting rejections dropped all over the place. (Okay, first it was #100, I'm an idiot.) I guess I will use .promisify rather than .method to get past my current silent failures but I'm frightened that there might be other circumstances where I'll miss a thrown error.
Unhandled rejections should be logged whenever there's an unhandled rejection, so 1 and 3 are bugs because you don't have any handlers for the rejection registered by the "start of the second turn".
Related
I am trying to utilize the MassTransit batching technique to process multiple messages to reduce the individual queries to be database (read and write).
If there is an exception while processing one/more of the messages, then the expectation is to fault only required messages and have the ability to process the rest of the messages.
This is common scenario in my use case ,what I am trying to establish here is a way to perform batch processing that caters for poisoned messages
For example, if I have a batch size of 10 messages, 10 in the queue and 1 persistently fails, I still need a means of ensuring the other 9 can be processed successfully. It is fine if all 10 need to be returned to the queue and subset re-consumed - but the poisoned message needs to be eliminated somehow. Does this requirement discount the use of batching?
I have tried below, however did solve my use case.
catching the exception and raising NotifyFaulted for that specific message.
modified sample-twitch application, to throw an exception to something like below , based on https://github.com/MassTransit/Sample-Twitch/blob/master/src/Sample.Components/BatchConsumers/RoutingSlipBatchEventConsumer.cs
file.
public Task Consume(ConsumeContext<Batch<RoutingSlipCompleted>> context)
{
if (_logger.IsEnabled(LogLevel.Information))
{
_logger.Log(LogLevel.Information, "Routing Slips Completed: {TrackingNumbers}",
string.Join(", ", context.Message.Select(x => x.Message.TrackingNumber)));
}
for (int i = 0; i < context.Message.Length; i++)
{
try
{
if (i % 2 != 0)
throw new System.Exception("business error -message failed");
}
catch (System.Exception ex)
{
context.Message[i].NotifyFaulted(TimeSpan.Zero, "batch routing silp faulted", ex);
}
}
return Task.CompletedTask;
}
I have dig into a few more threads that look similar to the issue ,for reference.
Masstransit error handling for batch consumer
If you want to use batch, and have a message in that batch that cannot be processed, you should catch the exception and do something else with the poison message. You could write it someplace else, publish some type of event, or whatever else. But MassTransit does not allow you to partially complete/fault messages of a batch.
Every time a Protractor element locator fails, it prints an error and continues down a horrible path of endless cascading failures in my spec and suite. Every test that follows depends on the element locator finding its element, and depends on the current spec passing.
I would like to keep the web page under test open while I use the console. The goal is to debug the current state of the page and investigate why the element locator may have failed to find its target.
I'm not too concerned about failing the entire suite and exiting on the first spec failure (I've seen other answers on --fail-fast and stopping on first spec failure.) This is not the approach I would like to take. I want to set a breakpoint, and inspect the environment while the page is running.
Maybe there's something like a Jasmine option for doThisOnFailure: () => { debugger }, which would work for me I think.
I really do not like the solution of using a spec reporter to execute during afterEach and check the failed spec count on the Jasmine environment for the entire spec function. I want to immediately know when an element locator has failed and immediately break as soon as it has failed.
Maybe something really gross would work $('element').click().catch(() => { debugger }).
EDIT: Please, note that I am asking about breaking in a spec, not breaking at the end of the spec.
it('should execute deadly code', function () {
p.navigation.openStorageConfigTab()
$$('.bad-selector').get(0).click() /* IMPORTANT: I want to break here */
p.volume.navigateTo()
})
it('should not execute this spec', function () {
$$('.bad-selector').get(0).click()
})
And the output
✗ should execute deadly code
- Failed: Index out of bound. Trying to access element at index: 0, but there are only 0 elements that match locator By(css selector, .bad-selector)
✗ should not execute this spec
- Failed: Index out of bound. Trying to access element at index: 0, but there are only 0 elements that match locator By(css selector, .bad-selector)
I can recommend you the approach I use, and I hope you can take it from here
Overall approach is to wait until until you type close/ command in browser url:
await browser.waitForAngularEnabled(false);
await browser.wait(
async () => {
let url = await browser.getCurrentUrl();
return url.includes('close/');
},
5 * 60 * 1000,
'Keep-alive timeout reached, closing the session...'
);
The question is when you want to call it. I use the advantage of onComplete callback function in config file. When it's called, the browser is still available. So once all tests are completed, it doesn't exit for 5 minutes unless I submit close/ to the url field. Obviously that can be conditional, by adding something like if (DEBUG === true)
A downside of this setup is it's called when all tests are completed, and it's possible your spec has navigated away from the page where there was error. So what you can also do is to use advantage of jasmine reporter (if you use jasmine). Roughly, you just need to add this to your onPrepare func:
jasmine.getEnv().addReporter({
jasmineStarted: function(suiteInfo) {},
suiteStarted: function(result) {},
specStarted: function(result) {},
specDone: async function(spec) {
if (spec.status === 'failed') {
await browser.waitForAngularEnabled(false);
await browser.wait(
async () => {
let url = await browser.getCurrentUrl();
return url.includes('close/');
},
5 * 60 * 1000,
'Keep-alive timeout reached, closing the session...'
);
await browser.close();
process.exit(35);
}
},
suiteDone: function(result) {},
jasmineDone: function(result) {},
});
So if any it block has failed status, then it'll stop. BUT, I have not tested it, I'll leave it up to you. And second, I didn't think about what will happen to the rest of queued specs since you're redirected to non existing url close/, but I believe it'll still work for you. Worst case scenario, you can play around and make it continue or close the browser instance, as long as you understood the concept
P.S.
I modified the code to close the browser when you type close/, by adding
await browser.close();
process.exit(35);
I tested this code with the following scenarios:
happy path: all 5 it are successful
first element finder of second it block fails
second element finder of second it block fails
All passed. The code works as expected
I am using Wow64GetThreadContext calling from a 64bit process on a 32 bit process. I am catching the WOW64 Context structure with this method.
The MSDN seems to no longer have the documentation for this method available, it is however still referenced on the GetThreadContext documentation page. I am not sure why this is. As the documentation is not available I am having a hard time figuring out why I am getting the error below.
The code where the error is being thrown is below. The error being thrown when I check GetLastWin32Error is: When the file already exists, the file cannot be created.
Does anyone have any ideas why it would throw this error? I am not creating a file at all which is confusing me.
ContextWow = new WOW_CONTEXT();
ContextWow.ContextFlags = CONTEXT_FLAGS.CONTEXT_ALL;
try
{
Wow64GetThreadContext(ThreadHandle, ref ContextWow);
if (new Win32Exception(Marshal.GetLastWin32Error()).Message != "The operation completed successfully")
{
throw new Exception("Win32 Exception encountered when attempting to get thread context" + new Win32Exception(Marshal.GetLastWin32Error()).Message);
}
}
Here is a link to the documentation you want, captured by the Internet Archive on July 10 2019:
Wow64GetThreadContext() function
Per the documentation:
Return Value
If the function succeeds, the return value is nonzero.
If the function fails, the return value is zero. To get extended error information, call GetLastError.
Your error handling is wrong. It is the equivalent of doing the following:
ContextWow = new WOW_CONTEXT();
ContextWow.ContextFlags = CONTEXT_FLAGS.CONTEXT_ALL;
try
{
Wow64GetThreadContext(ThreadHandle, ref ContextWow);
if (Marshal.GetLastWin32Error() != 0)
{
throw new Exception("Win32 Exception encountered when attempting to get thread context" + new Win32Exception().Message);
}
}
You are making a very common mistake of calling GetLastError() at the wrong time. As the documentation says, the Win32 error code is valid to use only if Wow64GetThreadContext() returns false, which you are not checking for.
What you are doing is not the correct way to check for an error (either to get the error code, or to perform comparisons on it). The correct code should look more like the following instead:
ContextWow = new WOW_CONTEXT();
ContextWow.ContextFlags = CONTEXT_FLAGS.CONTEXT_ALL;
if (!Wow64GetThreadContext(ThreadHandle, ref ContextWow))
{
throw new Exception("Error encountered when attempting to get thread context", new Win32Exception());
}
That being said, the error message you are seeing, "When the file already exists, the file cannot be created", is your system's text for the ERROR_ALREADY_EXISTS (183) error code, which is not an error code that Wow64GetThreadContext() is documented as reporting on failure, and really just doesn't make much sense for this kind of function to report on failure. So, what is most likely happening is that Wow64GetThreadContext() is actually returning true, but because you are not checking for failure correctly, you are actually seeing an error code from an earlier/internal API call that has not been overwritten when Wow64GetThreadContext() returns true, and so it should be ignored in this situation, not acted on.
I'm writing a kafka stream 2.3.0 application to count the number of events in a session window and hopefully to print out only the final record when a session times out.
Serde<String> stringSerde = Serdes.serdeFrom(new StringSerializer(), new StringDeserializer());
Serde<MuseObject> museObjectSerde = Serdes.serdeFrom(new MuseObjectSerializer(), new MuseObjectDeserializer());
StreamsBuilder builder = new StreamsBuilder();
builder
.stream(INPUT_TOPIC, Consumed.with(stringSerde, museObjectSerde))
.map((key, value) -> {
return KeyValue.pair(value.getSourceValue("vid"), value.toString());
})
.groupByKey(Grouped.with(Serdes.String(), Serdes.String()))
.windowedBy(SessionWindows.with(Duration.ofSeconds(INACTIVITY_GAP)).grace(Duration.ZERO))
.count(Materialized.with(Serdes.String(), Serdes.Long()))
.suppress(Suppressed.untilWindowCloses(Suppressed.BufferConfig.unbounded()))
.toStream()
.print(Printed.toSysOut());
However the application crashes when a session times out:
12:35:03.859 [kafka-producer-network-thread | kafka-streams-test-kgu-4c3f2398-8f67-429d-82ce-6062c86af466-StreamThread-1-producer] ERROR o.a.k.s.p.i.RecordCollectorImpl - task [1_0] Error sending record to topic kafka-streams-test-kgu-KTABLE-SUPPRESS-STATE-STORE-0000000008-changelog due to The server experienced an unexpected error when processing the request.; No more records will be sent and no more offsets will be recorded for this task. Enable TRACE logging to view failed record key and value.
org.apache.kafka.common.errors.UnknownServerException: The server experienced an unexpected error when processing the request.
12:35:03.862 [kafka-streams-test-kgu-4c3f2398-8f67-429d-82ce-6062c86af466-StreamThread-1] ERROR o.a.k.s.p.i.AssignedStreamsTasks - stream-thread [kafka-streams-test-kgu-4c3f2398-8f67-429d-82ce-6062c86af466-StreamThread-1] Failed to commit stream task 1_0 due to the following error:
org.apache.kafka.streams.errors.StreamsException: task [1_0] Abort sending since an error caught with a previous record (key user01\x00\x00\x01m!\xCE\x99u\x00\x00\x01m!\xCE\x80\xD1 value null timestamp null) to topic kafka-streams-test-kgu-KTABLE-SUPPRESS-STATE-STORE-0000000008-changelog due to org.apache.kafka.common.errors.UnknownServerException: The server experienced an unexpected error when processing the request.
at org.apache.kafka.streams.processor.internals.RecordCollectorImpl.recordSendError(RecordCollectorImpl.java:138)
I've tried to comment out ".suppress..." line. It works fine without suppress() and prints out something like this
[KSTREAM-FILTER-0000000011]: [user01#1568230244561/1568230250869], MuseSession{vid='user01', es='txnSuccess', count=6, start=2019-06-26 17:11:02.937, end=2019-06-26 18:07:10.685, sessionType='open'}".
What did I miss in using suppress()? Is there another way to filter out only the session records that have been timed out?
Any help is appreciated. Thanks in advance.
suppress() requires at least broker version 0.11.0 and message format 0.11.
I want to catch errors on the remote page in Casper.
casper.thenEvaluate ->
document.querySelector("#selector-doesnt-exist").attribute-doesnt-exist = 'value'
I have the following listeners set up:
casper.on "page.error", (message, trace) ->
console.log(message)
casper.on "remote.message", (message) ->
console.log(message)
Neither of these is being triggered when the evaluate fails. Is there any way to listen to errors on the remote page?
I don't know how to do this either, and there's probably a more proper way.
Assuming you only want to catch errors in your own evaluate code (not errors on the part of the site you're loading), one solution would be to wrap the casper evaluate function to include a try-catch, and handle the error by returning it from the evaluate:
casper.myevaluate = (fn, args...) ->
s = #evaluate (fn,args) ->
try
fn.apply(this,args)
catch e
return {'ourError':e}
, fn, args
if s.ourError?
ErrorHandler.Exception(s.ourError)
return s
E.g. calling:
casper.myevaluate ()-> silly
...would call your error handler code with ReferenceError: Can't find variable: silly