Email import errors

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • a.slyzhko
    Senior Member
    • Oct 2023
    • 126

    #1

    Email import errors

    Hi,
    we occasionally lose incoming emails because some messages fail to import. In logs we see two repeating errors:

    Code:
    ERROR: EmailAccount 67e563c63b1cdc4e9, import message; 22007 SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect string value: '\xD0' for column `espo`.`email`.`name` at row 1
    and

    Code:
    ERROR: EmailAccount 61a3511f0a13a5e8f, import message; HY000 SQLSTATE[HY000]: General error: 1020 Record has changed since last read in table 'email_user'
    Also similar to the second one, but with 'entity_team' table, occurs from time to time, but less frequently than with 'email_user'.

    Environment: Ubuntu 22.04, MariaDB 11.8, EspoCRM 9.2.5.

    Does anyone know what typically causes these, and how to prevent the import from failing? Any suggestions appreciated.
  • rabii
    Active Community Member
    • Jun 2016
    • 1384

    #2
    i guess that the first error has nothing to do with import failing - as first error is just that your instance tried to save an email with a subject that contains an invalid or non-UTF-8 character (\xD0). MySQL rejected it because the database/table/column is not using utf8mb4.

    However from the second error is different and it show that this could an optimistic concurrency failure - meaning while the import is running there could be another process running for the same resource and the resource keeps changing.

    Try to activate parallel cron job.
    Rabii
    EspoCRM Custom Development

    ๐Ÿ”— Portfolio & Builds

    Comment

    • Rafael03
      Junior Member
      • Dec 2025
      • 6

      #3
      If your MariaDB tables are still on the older utf8 charset, definitely upgrade them to utf8mb4. It's almost always a weird character in the email subject causing the crash. As for the 'Record has changed' error, itโ€™s definitely a locking issue - parallel cron is the right move, but also double-check that your server's system time is perfectly synced (NTP), as tiny offsets can sometimes mess with record timestamps in high-volume imports.

      Comment

      Working...