Bitrix24 open lines that never close: Wazzup messages dated the year 58520

Open line sessions stopped closing on their own. Auto-close was configured, timeouts were set, and dialogs still stayed open for weeks. Operators' unread counters kept climbing and the database kept growing.

The log showed why: almost every incoming WhatsApp message reached the portal dated the year 58520.

What the log showed

I took five days of imopenlines.log: 57 MB, about 30,000 events. On this portal 96% of open line traffic came through Wazzup (WhatsApp).

Incoming CONNECTOR - ENTITY ADD events carry a message date. In 7,111 of 7,224 cases (98.4%) it looked like this:

[date] => 58520-02-06 18:00:01.000000

The same log also had correct dates: 1784705238 and 2026-07-20T06:45:25-06:00. So the portal handles time correctly in general, and one source breaks it.

Where the year 58520 comes from

With the integration settings this portal had, Wazzup sent the message time in milliseconds: 1784705238000, thirteen digits. The connector on the Bitrix24 side reads that number as seconds. 1,784,705,238,000 seconds after 1970 lands in the year 58520.

The correct value in seconds, 1784705238, is July 20, 2026. Three extra zeros.

Why it matters

A wrong date on a message looks harmless. In practice it switches off the cleanup.

Open line agents close and purge sessions with a simple rule: the last change happened earlier than "now minus the timeout". A session dated 58520 never matches that rule. It stays open forever, and everything attached to it stays too:

• the chat and its members;
• operators' unread counters;
• session service records, indexes, response statistics;
• a slot in every operator's recent dialogs list, which the portal walks through each time chats are opened.

Date indexes stop helping once a table holds records "from the future", and history queries read more rows than they need. The same log had 81 NO LAST SESSION errors, where the portal could not find a client's last session. Most likely the broken dates caused those too.

For scale: open lines produced 83% of all messages on this portal, about 4,000 a day, a million and a half a year. Every session that fails to close leaves its rows in the database for good.

Why nobody notices at launch

An integration gets tested like this: send a WhatsApp message, see it arrive in Bitrix24, the operator replies, the client receives the reply. Everything works, the task is closed.

Nobody checks the message date in that test. The interface barely shows it, and the damage builds up in the database for months. By the time the portal slows down, the integration has long been considered done, and the search starts elsewhere: hardware, cache, "Bitrix is just heavy".

Integrations often go this way. Teams check that data arrived. They rarely check what shape it landed in and what happens to it six months later.

What we did

We fixed it in three steps, and the order matters. Then we added a safeguard for the future.

First, stop the flow of broken dates. As long as new messages arrive from the year 58520, any cleanup is pointless: within an hour there are new sessions that will never close. So we fixed the problem where it starts, on the Wazzup side, by configuring it to send the date in the format Bitrix24 expects. The portal code stayed untouched, so a Bitrix24 update cannot roll the fix back.

Checking the result is easy. New CONNECTOR - ENTITY ADD events in imopenlines.log show today's date again, and the count of messages from the future (the first query at the end of this article) stops growing. Once the setting changed, dates started arriving in the right format.

Then close what was already stuck. New messages were fine now, but the old sessions still carried dates in the future. Auto-close would never pick them up, so we wrote a script that closed every open chat.

They have to be closed, not deleted from the database. An open line session is tied to a chat, its members, operators' unread counters and statistics. Delete the session and leave the rest, and you get orphans: a chat with no session sits in an operator's list, the counter never resets, and the portal logs errors like NOT_LOAD_SESSION_OR_CHAT whenever someone touches that dialog. The log already had a couple of those. A proper close frees the chat, removes the operators, resets their counters and records the result in statistics. That is the work auto-close should have been doing all along.

Only after that, clean up the bloated database. Carefully: the open line and message tables are large, and a careless delete on a live portal is expensive. Take a fresh copy of the database before a cleanup like this, because without one there is no way to undo a delete.

Finally, add a watchman. Someone can change the integration setting by accident, or Wazzup can update its side, and the dates will drift again. Finding out six months later because the portal is slow is not an option, so we added a simple check built on Bitrix24 lists. Every incoming message creates a list item, and items are kept for one day. If the year in a message date differs from the current year, a notification goes straight to the Bitrix24 administrator and the head of IT. Now an outage like this gets noticed right away, and there is time to react before the database grows again.

The same log showed a second, non-technical cause of hanging sessions. Staff picked up colleagues' dialogs, but their role lacked the "close other operators' dialogs" permission. Each attempt to close failed with ERROR_USER_NOT_OPERATOR, 60 to 90 times a day, and the dialog stayed open. One checkbox in the line's permissions fixes it.

How to check your portal

If your on-premise portal runs open lines through Wazzup or another messenger connector, these queries show whether you have the problem:

-- messages and sessions dated more than a year ahead
SELECT COUNT(*) FROM b_im_message          WHERE DATE_CREATE > NOW() + INTERVAL 1 YEAR;
SELECT COUNT(*) FROM b_imopenlines_session WHERE DATE_CREATE > NOW() + INTERVAL 1 YEAR;

-- how many sessions are open right now
SELECT COUNT(*) FROM b_imopenlines_session WHERE CLOSED = 'N';

If MySQL is not in strict mode, you may find 0000-00-00 instead of a future date. Look for that too.

If you have thousands of open sessions while operators handle dozens of dialogs, look at the [message][date] field of CONNECTOR - ENTITY ADD events in imopenlines.log. And check in the line settings whether staff can close dialogs they took over from colleagues.