Child pages
  • [emails] EmailLog doesn't store Emails with Very Long Body when sent via Mailing List [5.2.0-RC1]
Skip to end of metadata
Go to start of metadata

Imported from: http://groups.google.com/group/in-portal-bugs/browse_thread/thread/8493d284eff6c16c#

Hi all,

Recently in 5.2.0 we have introduced complete Email Logging which is quite useful.

However, there seems to be a bug in Logging emails with very Long Email Body that are sent via Mailing List functionality. In particular this happens when we send emails with HTML in it (see attached).

Problem lead to the amount of data being stored in LogData column of EmailQueue table. Currently this field is a TEXT which is not enough to store Serialized logging data (html + plain versions) in it. I total ti takes (around 130kb). Then  I have tried LONGTEXT, but it also failed why LONGBLOB worked out fine.

Strange enough we can see here that LONGTEXT should be a good match for this, but for some reason it didn't work

TINYTEXT 256 bytes  
TEXT 65,535 bytes ~64kb
MEDIUMTEXT 16,777,215 bytes ~16MB
LONGTEXT 4,294,967,295 bytes ~4GB

Test-MailingLog.txt

Related Tasks

INP-1109 - Getting issue details... STATUS

6 Comments

  1. maybe because BLOB let you encapsulate data that breaks longtext format.

    Envoy

  2. Alex, any thoughts on this?

    DA

  3. Nope. We used to have problems with text not saved completely (only first
    64kb) with content blocks, but text was saved partially at least. Then
    changed to "longtext" from "text" and problem was solved.

    No idea (need to test) about why such long text doesn't fit in longtext
    column.

  4. Looks like we've got to the bottom of this issue. Our LogData column can't
    be TEXT type since it contains Serialized strong which contains New Lines
    and so on. It will only work when we try saving it in Binary type BLOG - it
    can be MEDIUMBLOB - should be sufficient.

    DA

  5. Task:

    INP-1109 - Getting issue details... STATUS


  6. Patch attached, ready for testing.

    Problem was because of "©" symbol in HTML e-mail was converted to
    symbol with 163 ASCII code for plain text e-mail version but wasn't then
    UTF-8 encoded. Actual e-mail was sent out in UTF-8 encoding.

    In a result we had 2 problems with that symbol in plain text e-mail version:

       1. symbol was displayed as "white square" or "black diamond with
       question mark in the middle"
       2. when INSERT statement was made into EmailQueue database table then
       data after that symbol (in LogData column) wasn't stored to database.