Matomo 5.6.0 AIAgents – ai_agent_name column not created, core:update hides InnoDB row size error (#1118)

Hi,

on a large self-hosted Matomo instance (InnoDB, piwik_log_visit ≈ 30 GB, very wide table), enabling the AIAgents plugin in Matomo 5.6.0 leads to an inconsistent DB state.

After enabling the plugin and running:

php /var/www/piwik/console core:update

the CLI shows:

Executing ALTER TABLE `piwik_log_visit` ADD COLUMN `ai_agent_name` VARCHAR(40) NULL;... Done. [1 / 1]

Matomo has been successfully updated!

However, the column is not actually added. Running the same statement manually:

ALTER TABLE `piwik_log_visit` ADD COLUMN `ai_agent_name` VARCHAR(40) NULL;

returns:

ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126.

So the ALTER TABLE fails at the DB layer, but core:update still reports success and does not surface the error. The AIAgents plugin then assumes the column exists and breaks.

Workaround on such large/wide installations:

ALTER TABLE `piwik_log_visit` ROW_FORMAT=DYNAMIC;  -- full table rebuild, very expensive on ~30 GB
ALTER TABLE `piwik_log_visit` ADD COLUMN `ai_agent_name` VARCHAR(40) NULL;

Request / Suggestions:

1. core:update should not print “Done” / “Matomo has been successfully updated!” if the underlying ALTER TABLE fails (e.g. with error 1118). The DB error should be visible in the CLI.

2. For log_visit migrations (like adding ai_agent_name), Matomo should:

   • either pre-check row format / row size and warn about the 8126-byte InnoDB limit,

   • or at least catch error 1118 explicitly and show a clear message (e.g. advising ROW_FORMAT=DYNAMIC or converting large VARCHARs to TEXT).

Right now, on big installations, this migration silently fails, leaves the schema incomplete, and the plugin in a broken state.

Best,
Andy

1 post - 1 participant

Read full topic