Repository navigation
FileAdapter errors ignored #661
Description
If a FileAdapter returns an error it is later ignored in the file router:
// FileRouter.js
}).catch((err) => {
// err is ignored
next(new Parse.Error(Parse.Error.FILE_SAVE_ERROR, "Could not store file"));
});The S3Adapter for example returns an error with the following message when the keys are wrong: The request signature we calculated does not match the signature you provided. Check your key and signing method. Would it somehow be possible to propagate this error to the developer?
Metadata
Metadata
Assignees
Labels
No labels
Activity
simonbengtsson commentedon Feb 26, 2016
I thought of making a PR, but I'm not entirely sure what would be best here. Simply replacing the "Could not store file" message with the one from the adapter like this?
chriscborg commentedon Feb 26, 2016
Hi @simonbengtsson - This line worked for me if it helps:
So I guess your code should work as well.
simonbengtsson commentedon Feb 26, 2016
The question I guess is how much the adapters should be able to choose what error messages get sent to the developer. Probably it makes sense to let the adapters fully decide. It will require some changes to the adapters though to make them send better formatted errors.
flovilmart commentedon Mar 1, 2016
There will be a need in the files adapter to return a 'standard' response as for now, when you save through the GridStore adapter or the S3Adpater, the responses differs. The FilesController is ignoring that response and returning a pre-cooked one.
simonbengtsson commentedon Mar 1, 2016
Should the goal be that every subclass of
FileAdaptershould return a Parse.Error that can be passed directly to the user?flovilmart commentedon Mar 1, 2016
that would be nice to have something standard yes, doesn't have to be a Parse.Error as the *Controller is responsible for formatting
parthtiwari65 commentedon Mar 5, 2016
Where can I find the file, " FileRouter.js " to make these changes?
I don't see this file in my Parse server copy.
hawkit commentedon Mar 10, 2016
@flovilmart I have changed FileRouter.js as following :
next(new Parse.Error(Parse.Error.FILE_SAVE_ERROR, 'Could not store file: ' + err));at EC2 instance. but why i still get same error asDo I need to restart EBS to make it work?
jdzorz commentedon Mar 10, 2016
@parthtiwari65 it is under node_modules/parse-server/lib/controllers/FilesController.js
@hawkit yes restart your EBS
hawkit commentedon Mar 11, 2016
@parthtiwari65 it is here: /var/app/current/node_modules/parse-server/lib/Routers/FilesRouter.js
hawkit commentedon Mar 11, 2016
@jdzorz thanks a lot. It works!
wavo89 commentedon Mar 14, 2016
I'm using Heroku- how do I make sure that this change is active on the server? When I changed it and went to git add/commit/push, it said that there weren't any changes to save.
abbasdawood commentedon Jun 14, 2016
@jdzorz I can't seem to get this fixed even with parse-server (latest), on modifying the default error message this is what I see on console
ParseError { code: 130, message: 'Could not store file.InvalidParameterType: Expected params.ContentType to be a string' }I understand the Parse.File constructor takes in the MIME type as the 3rd parameter, so I set this manually - which didn't help either. I also think there were some modifications in 2.1.3 to auto detect the MIME type of the uploaded file, so I don't know why MIME has to be provided anyway.
Don't think anything is wrong with the S3 configuration / policy, since images are saving properly. This particular issue is only for .csv files.
Any help would really be appreciated :)
5 remaining items
hubertott commentedon Jan 24, 2017
@abbasdawood if this was indeed your problem, perhaps we should be updating the example on this page.
https://github.com/ParsePlatform/parse-server/wiki/Configuring-File-Adapters#passing-as-options
acinader commentedon Jan 24, 2017
I think I have solved this with: #3424
BUUUUT, read on, cause i think that there is more to do here....
So this one has been bugging me for awhile :).
Sometimes, an error will result in a very unhelpful:
[object Object]output on console.error.Stuff should not be output on console.error. Users of parse-server should expect that errors will be output to the logger, not the console.
the error message is totally useless!
The output is coming from: the 'backstop' next() handler that is called at the end of an express request if 'something' isn't done to prevent it.
this calls this
In my case, the error was due to a misconfigured s3 adapter. And I fixed the lack of this particular error with this change: #3424
But I KNOW that there are other places where the dreaded
[object Object]output to console.error occurs and it would be good if we could put in a good backstop.SOOOOO, I see that middleware.js gets called, generates a response and then calls the final backstop in express.
With a nice TODO:
// TODO: Add logging as those errors won't make it to the PromiseRouterit would seem to me that three changes are needed to make a general solution that will allow us to remove that todo:
Extend Parse.Error (Parse.ServerError?) to add the optional param 'Source' with the source error.
log the source error in middlewares.handleParseErrors
find all places where we
new Parse.Errorchange to Paerse.ServerError and add a source error if/when appropriate...remove the next() from the end of the middlewares.handleParseErrors.
I'm game to do it, but want to make sure I am on the right track since I'm no express expert...yet :).
PS, it would also seem reasonable to redefine console.log, console.warn, console.error to logger.info....etc.?
flovilmart commentedon Jan 24, 2017
@acinader, on the paper, renaming console.* makes sense, however, that could lead to unexpected behavior from cloud code for ex.
acinader commentedon Jan 24, 2017
@flovilmart ok, agreed, overriding console will likely cause all kinds of havoc. how about extending Parse.Error with Parse.ServerError? Sound good to you?
flovilmart commentedon Jan 24, 2017
Or plain Error no? There was some complaints that Parse.Error is not a subclass of Error.
acinader commentedon Jan 24, 2017
k. buy that too. i'll take a crack at it.
so i think we can hold on #3424 for now. if this works, then we can close it.
flovilmart commentedon Jan 24, 2017
Excellent!
Log Parse Errors so they are intelligible.
Log Parse Errors so they are intelligible.
Log Parse Errors so they are intelligible. (#3431)