I'm using the NestJS #FilesInterceptor to parse an array of files in a multipart request, here's how I use it:
#FilesInterceptor('files', 3, { some other options })
I need a specific error to be thrown if more than 3 files are sent, but what I get is a socket hangup client-side
Error: socket hang up
and this is the error logged in the console of the server:
Error: Unexpected end of multipart data
In the end: server crashed :(
So, how can I catch this error to handle it and prevent crashing?
It doesn't seem to be an instance of HttpException so the exception filter is not useful.
I could have done the length check in the controller, but I need { some other options }, so I must set a value for the maxCount
I found out the problem: the server has a global interceptor that implements a timeout for incoming requests. If I remove it, then the error is parsed correctly to an HttpException the client gets a BadRequest as expected
I'm still confused about why this doesn't work when I put it all together...
Related
my requirement is to sent the error http status and error message in the body.
In Case of error in flow i need to pass the http code in the status field.
I can configure this http listner but don't know how to set this to get into payload. Please guide on that.
I'm expecting the MEL to get the 400 Bad Request
{
'status': "400 Bad Request",
'message': error.description
}
I could think of 2 ways of doing this:
1.You can use RAML and for every status code you can send appropriate responses as per your use case.This I think is the best way of doing it.
2.You can have the value for status and message key of your response body inside error handling block.Configure the 'TYPE' condition of your error handling block to catch a certain HTTP error message , then inside that you can set 2 vars: one with the status value and other with message value.Then use this vars in the Error response section of HTTP listener. You'll be ending up with many such error handling blocks if you want to address multiple status codes.
Let me know if you need further clarifications.Hope it helps.
I'm currently handing off exceptions to a third party telemetry tracking service (Raygun). One of the details I want to include in those exception logs is the actual contents of the message, ideally serialized to JSON.
I'm handling this at the end of the MessageHandler. I'm aware that I could also use the IManageMessageFailures interface, but then I lose the benefits of the second level retries.
I'm currently doing this:
public void End(Exception e)
{
// get the current message context
var context = this.Bus.CurrentMessageContext;
// now where do I get the body of the message from?
this.ExceptionLogger(new Log(e, context.WhereAreYouMessage.SerializedAsString()));
}
This is NSB 3.3. I notice that I can cast the CurrentMessageContext to NServiceBus.Unicast.MessageContext, but the TransportMessage property which contains the message Body is private.
How can I get a copy of the message that caused the exception?
This is not supported in version 3.
You can look in your error queue which will have the exception details correlated with the message body http://docs.particular.net/nservicebus/errors/#configure-your-error-queue
I have a question regarding to Nest1.0pr and the connection error handling. In the previous versions of Nest I was using IResponse.ConnectionStatus.Error. It seems to me that the property Error does not exist in the new version anymore. However in the documentation I found the following:
ConnectionStatus is the response as it was returned by
Elasticsearch.net. It's section on handling responses applies here as
well.
And in the very section the property Error is mentioned.
Error When a call succeeds but does not return a http status code of
200 this property will have details on the error. Read more about
error handling here
So is the recommended way to check whether the property Success is false?
TIA
This changed when NEST was refactored to use Elasticsearch.Net. Now when a request fails, you can try checking the IResponse.ConnectionStatus.OriginalException property, which will contain the actual Elasticsearch error.
When I Uncomment this line for api documentation
//// Uncomment the following to use the documentation from XML documentation file.
config.SetDocumentationProvider(new XmlDocumentationProvider(HttpContext.Current.Server.MapPath("~/App_Data/BitCoinWrapperAPI.xml")));
I received an error :
An exception of type 'Microsoft.Practices.ServiceLocation.ActivationException' occurred in Microsoft.Practices.ServiceLocation.dll but was not handled in user code
Additional information: Activation error occured while trying to get instance of type HelpController, key ""
When I call the Index page in the HelpController of the API, anybody knows why?
Well I added this line and it works without exception
ObjectFactory.Configure(x => x.SelectConstructor(() => new HelpController()));
I'm trying to get SimplePie to fail gracefully if one of the feeds I hand it turns out to be unavailable or invalid (due to server issues on the feed provider's end)
The code I've got is this:
$this->feed= new SimplePie();
// Set which feed to process.
$this->feed->set_feed_url('http://my_feed_goes_here'); // Bogus
$this->feed->handle_content_type();
// Run SimplePie.
$this->feed->init();
The problem is, if the feed_url turns out to be invalid, I get the following error as soon as it hits $this->feed->init();
Fatal error: Call to undefined method DOMElement::getLineNo()
I've looked through the documentation, and I can't see anything about validating. I did see this page about error checking (http://simplepie.org/wiki/reference/simplepie/error) but that only really works if the URL is completely invalid and fails to load. In a case where the URL comes back with a 404, or something else that is not a valid feed, $feed->error is blank.
Isn't there some mechanism built into SimplePie to allow me to see whether I got a valid feed back, so I can fail gracefully if I didn't?
In SimplePie 1.3.1, ->init() will return false if it can't read or parse the URL, so you might do this:
if (! $feed->init()) {
// log your error, "return false" or handle the failure some other way
}
Based on my reading of simplepie\library\SimplePie.php, it doesn't generate any exceptions and that's why Try/Catch won't work.
This may not be built into SimplePie, but in your calling PHP you could use a try/catch block:
try {
$this->feed->init();
} catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), "\n";
}
Although depending on the error, this might not work either.