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

Support & Bugs
1

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 Like
2

Hi,

we hit the same class of problem again, this time during the Matomo 5.11 update.

The migration should add:

piwik_site.description

but the column was not created. Afterwards core:update still reported:

Everything is already up to date.

As a result, the installation was left in an inconsistent state: the Matomo 5.11 code expects the column, but the database schema does not contain it. Calling SitesManager.addSite then fails with:

Mysqli prepare error: Unknown column 'description' in 'INSERT INTO'

Trying to add the column manually shows the real underlying problem:

ERROR 1118: Row size too large

The affected table still had:

Row_format: Compact

Workaround:

ALTER TABLE `piwik_site` ROW_FORMAT=DYNAMIC;

then add the missing column.

The dangerous part here is not only the InnoDB row-size issue itself, but that the updater appears to swallow / hide the failed migration and still reports the installation as up to date.

Could this please be handled more strictly? If a migration fails with ERROR 1118 or any other SQL error, core:update should fail loudly and clearly. Silently ending up with missing columns while the application code expects them is really dangerous and can break production installations in unexpected places.

Best,
Andy

ps) Pinging @maxtaube here because this seems related to the 5.11 description-field migration introduced in PR #24501. Maybe also @tsteur, since the dangerous part is that core:update appears to mark the update as successful even though the underlying ALTER TABLE failed with ERROR 1118.

The main issue for us is not only the row-size problem itself, but that the failed migration is silently swallowed and the installation is left in an inconsistent state.

1 Like
3

Quick update from our side:

We prepared a small PR that addresses the dangerous part of this issue: unexpected exceptions during core updates should not be treated as warnings and should not allow the core version to be marked as successfully updated.

The PR changes the updater behavior so that unexpected exceptions during core updates are converted to UpdaterErrorException and go through the existing core error handling path. Plugin update warning behavior remains unchanged.

This does not directly fix the underlying InnoDB row-size problem, but it should prevent Matomo from silently ending up in an inconsistent state where core:update later reports “Everything is already up to date” while required schema changes were not applied.

PR: https://github.com/matomo-org/matomo/pull/24639

Best,
Andy

1 Like