@alxndrsn Thanks for posting, we'll take a look as soon as possible.

For help with questions about Sails, click here. If you’re interested in hiring @sailsbot and her minions in Austin, click here.

@alxndrsn I see where you're coming from, although I don't entirely agree with this:

which doesn't really make sense in production systems

We rely on these logs in our own production systems, and having extra information (especially when it comes to stack traces) can be really helpful to figure out which customers/orders/etc. were affected.

That said, it would make sense to me to have the option for fewer troubleshooting tips, etc in production for a lot of the errors (and especially some of the warnings).

I'm not sure adding a new config setting is the right way to go, though (I've learned the hard way it's easy to add those and much much more annoying to maintain them).

Maybe what we should do is identify some specific examples of errors that are too long (i.e. drop a github link to the line of code where they come from -- easiest way to find that is to search github for a chunk of the error msg). Then we'll be able to address improving them (or conditionally shortening them) on a case by case basis.

Re: conditional shortening, I'm thinking it would probably work the same way as how production stack traces work (i.e. normally we improve stack traces by instantiating Error instances called omens -- but we skip doing that in prod because it has a (albeit small) negative impact on performance. We do that based on env vars: we'd shorten only if either NODE_ENV==='production' and DEBUG is not truthy).

@mikermcneil thanks for the considered response.

We rely on these logs in our own production systems, and having extra information (especially when it comes to stack traces) can be really helpful to figure out which customers/orders/etc. were affected.

I've found the content of these errors very helpful including in production. My issue is specifically with error messages which include linebreaks: in production these are written as multiple log entries which are very hard to filter out.

If we could just remove the linebreaks, this would immediately solve my problem.

@alxndrsn that makes sense! OK, so then I think the next step is for us to identify some specific examples of production errors that are too long (i.e. drop a github link to the line of code where they come from -- easiest way to find that is to search github for a chunk of the error msg). Then we can address them one by one.

There are probably errors that you see during dev that should still probably span multiple lines (e.g. sails CLI related stuff), but for the other errors, I'm down to look at consolidating them onto a single line. (We'll just have to deal with it on a case-by-case basis)

👍

My original example was https://github.com/balderdashy/waterline/blob/master/lib/waterline/utils/query/process-all-records.js#L19-L34, but it looks like many error messages in https://github.com/balderdashy/waterline/blob/master/lib/waterline/utils/query/process-all-records.js include line breaks.

Sure enough - I'm cool with all of those living on a single line, because they are oftentimes seen in production logs (although in my experience, if they're showing up in production logs, that's a bad sign, because it means there needed to be some migration that didn't happen. Still, it'd be nice to actually be able to read what's going on in that situation! Or to be able to have an alert that neatly reports it in a Slack channel, etc)

PR at balderdashy/waterline#1606

@alxndrsn just took a look at your PR and added some feedback, let me know what you think: balderdashy/waterline#1606 (comment)

Changing content of error messages will break tests that have expectations of a certain response/error.

EDIT: Initial comment in opposition, I have thought about it longer now and support @alxndrsn

The referenced PR will add a non-zero amount of work , for what I can only interpret as a cosmetic change. I would support an option, as stated in title, but oppose breaking existing behaviour. Just my 2c though. in updating existing tests but single line (and thus single error message) is "the right thing to do".

Single line of error = one error. Currently the multiple lines of errors are being treated as multiple errors by logging tools