Email Forwarding loses all body text upon sending about nylas-mail HOT 8 CLOSED

That warning is thrown from (tryReadBody) the function above the one you highlited. (On my mobile) unless I missed something that function does not call pathForBodyFile.
Edit: Nice ninja edit 👍

from nylas-mail.

Is this issue occuring in our fork only?
Note: this works fine for me in Nylas stable.

from nylas-mail.

The log references this piece of code:

https://github.com/nylas-mail-lives/nylas-mail/blob/master/packages/isomorphic-core/src/message-body-utils.es6#L31

if (remainingId) {
    while (pathGroups.length < MAX_PATH_DIRS) {
        pathGroups.push(remainingId.substring(0, 2));
        remainingId = remainingId.substring(2);
    }
}

I think this error could be solved checking if remainingId is not undefined in the while condition. If it's checked outside, remainingId will eventually become undefined and the line pathGroups.push(remainingId.substring(0, 2)); will throw an exception.

EDIT: Debugging I realized that the error is being thrown here:

from nylas-mail.

You're right, the problem is in tryReadBody. As far as I could see it's happening with emails sent from the client-app. If I send an email from outside (let's say gmail, for example) the email is received and the body is parsed ok. I'm still debugging, let you know if I find something

from nylas-mail.

The error seems to be the client-app creating the file to save the email body when we create a new message, but not updating it at all. The file doesn't get updated because the writeBody function is called with forceWrite = false every time. I think we can change it to set forceWrite = true whenever the message is a draft. In one picture, what I propose is this change:

As far as I tested it solves the problem and doesn't have a negative impact on performance because the file is written just 2 times (vs 1 before the change): one when we click on 'New message' and the other when we send it.

@dweremeichik if it's ok for you I can make a PR

from nylas-mail.

@agurz PRs are absolutely welcome! Once you submit one, we will likely get more eyes on it.

from nylas-mail.

So I see why it is not updating, like you stated. I suppose I would need to debug it myself to understand exactly why that function was designed that way, they have comments saying that it is slow to write to the file system, and if they can't write to the file system, they fall back to the DB. What bugs me is they aren't diffing the files at all, it's simply a test of whether the file exists or not. Perhaps their intent is to save interaction with the filesystem. Which means that they would always need to know before hand when they needed to update the file, hence the force write as you suggested. Sorry for the rant, verbalizing my thoughts... Based on what I see, you are doing the right thing @agurz.

from nylas-mail.

putting this here for future reference. in the new code drop from nylas, nylas/nylas-mail@af3de33 removes forceWrite altogether. i'm keeping nylas' change (removing it) instead of our change (changing it) for the code dump merge. if this isn't right, we'll need to open another issue

from nylas-mail.