Mautic 6.0.2 to 6.0.3 Update Can’t DROP INDEX `mtc_company_match` Error

Hello,

Mautic update 6.0.3 has recently been released and I have been eager to install it.

However when you try and upgrade Mautic 6.0.2 to 6.0.3 then it fails with the same error as this post below.

Looks like the code to do the actual upgrade has not been fixed in the 6.0.3 release.

This confirm my suspicion that very little testing effort is being done to confirm upgrades will install error free putting users databases at risk.

Yes I know Mautic 5.x is the favored release and 6.x should be by passed however if its an official release then at the very least the upgrade process should work. And if there is a bug in the upgrade code then it should be fixed in the next release so that users databases are not put as risk.

Thanks.

2 Likes

Hello!

Thank you for pointing it out, I think there is never enough testing. One of the reasons is, that Mautic users are not aware how to start with tests and how to communicate with developers during testing.
I would be happy to onboard you next week, if you are interested in helping out in that area.
You can any time PM me.
Joey

Just installed 6.0.4 yesterday and upgraded to 6.0.5 today, and got this same error. The composer upgrade procedure needs to be clearer and enhanced.

I have fixed the error in the two problem files and completed the migration successfully.
I include the two fixed files. Download the file, rename its extension to .php, and then upload it to your 6x instance. Finally, re-run the command.

Hello johnwick,

Great news you have found the root cause of this issue and hopefully it will be applied to future releases in due course.

I’m currently running a production version of M6.0.3 and have not yet run an upgrade on this instance, Will the above files also work for migrating from M6.0.3 to the latest version of M6.x ?

I thought it a good idea to ask before making an attempt.

Thanks.

I had same “can’t drop index” errors and my “mautic expert” hosting company aslo could NOT solve it.. even with all ChatGPT + Claude AI help, and i also did all commands as they told and searched all forums, etc. and the “can’t drop index” came up even after full composer install, and even on full empty and new database on mautic 6.0.5 with very new almost 100% compozer fresh install also. So please solve that because it seems that bug is comiing up again and again in different forms (indexes) with every upgrade when someone migrated through from an earlier non compozer mautic.. :frowning:

Thanks, i tried it, but it did not solve my problem. So this is also one confirmation for me that this whole ‘can’t drop index’ is NOT just in this or that “VersionXY” file from migrations folder, because MAYBE you could solve that those 2 files IF your “can’t drop index” was caused by THOSE 2 files, but this “can’t drop index” can be caused by MANY THINGS, so not just from those 2 files, because your 2 file did not solve mine, and on every forum the “can’t drop index” is coming up for many different mautic tables, and for MANY different mautic versions, so thanks for your 2 files but even if they work for those who’s “can’t drop index”-es are caused by those 2 migrations this is just a very little “surface level partly solution” because every guy seems to have a slightly different “can’t drop index” problem, i checked many many forums, BUT in every version, so many files could cause the cant drop index not just those 2 files what you fixed! And even if the first time the schema update finises "with green ok” on fresh new empty database even after the same command instantly it gots the can’t drop index again… and if everybody ran into different shared hosting limits when was migrating from mautic 2 then the hole ROOT must be solved of this problem not just the “1-2 surface instances” every time.. because if the root is not solved than EVERY mautic upgrade ALSO IN THE FUTURE will be a NIGHTMARE even if every time someone solves it “ON THE SURFACE” but it really would need the REALLY DEEP LEVEL ROOT cause CURE!

IF you all want mautic to spread like wildfire because it is i am sure the real root blocking problem to that because every other problem can be solved with chatGPT or other AI or “good mautic host” but that “can’t drop index” or other similar MAPPING problems from ENTITIES like
doctrine:schema:validate seems not, like:

Mapping

[FAIL] The entity-class Mautic\DynamicContentBundle\Entity\DynamicContentLeadData mapping is invalid:

  • The association Mautic\DynamicContentBundle\Entity\DynamicContentLeadData#dynamicContent refers to the inverse side field Mautic\DynamicContentBundle\Entity\DynamicContent#id which is not defined as association.

    So i think these are caused by only ONE root cause, what generates TONS of errors in a slightly different form like these like “can’t drop index” with every upgrade or “entity mapping”, and even the most professional mautic experts says that this has NO official fix FOR THE ROOT cause!!

    So i dont know why are those issue tickets are almost all closed..

    But if you have 1 terrorist who burns down again and again many houses in each months, then you do not only have to just extinguish the fire everywhere on the houses, but the really smart move would be to catch the terrorist, the root cause, or not? And if the root cause is in doctrine itself than maybe mautic professionals should be connected to much more to the root developers of doctrine or at least talk to them, or something like that or not? :slight_smile:

Hello,

More and more end users are encountering these Mautic upgrade errors. I have been reporting them for a while and the developers are ignoring the problem.

I don’t understand why the developers expend time and effort releasing new versions if we cannot install them because of this upgrade error. Are you hoping that M7 when released will resolve the problem ?

Surely the developers priority should be to focus their attention on fixing this problem so that we can install new version as and when they are released.

Could a developer please explain their rational for not fixing this problem quickly ?

Thanks.

Hi all,

These migration issues have been plaguing me for a while now. I’ve been putting them on the “deal with later list” for as long as I could. Unfortunately (or fortunately depending on how you look at it), I finally had to sort it out as I’m running Mautic in a Kube cluster and can’t have restarting pods failing due to this.

I tried a few things including forcing “migrated” status on each migration, but that appears to cause some missing schema.

I was on a fresh install of Mautic using the 6.0.5 docker image.

NOTE: I found out the docker image environment variable option DOCKER_MAUTIC_RUN_MIGRATIONS does not do anything in 6.

The migrations that were failing for me were:

  • Version20211020114811
  • Version20211209022550

Version20211020114811 - Failing due to the missing index (can’t drop)

I shelled into the container, patched the file then proceeded - this only works because the migration is recorded as succeeding so it doesn’t run again when the container restarts and clears the patch.

Docker: docker run -it --entrypoint /bin/bash mautic/mautic:6.0.5-20250904-apache

Kuberenetes kubectl exec -it <pod-name> -- /bin/bash

Patch the file:

patch app/migrations/Version20211020114811.php << 'EOF'
> 58,64c58,67
<         $this->addSql(
<             sprintf(
<                 $dropIndexQuery,
<                 self::INDEX_COMPANY_MATCH,
<                 $this->getPrefixedTableName(self::COMPANIES_TABLE)
<             )
<         );
---
>         if($schema->getTable($this->getPrefixedTableName(self::COMPANIES_TABLE))->hasIndex(self::INDEX_COMPANY_MATCH))
>               {
>                       $this->addSql(
>                               sprintf(
>                                       $dropIndexQuery,
>                                       self::INDEX_COMPANY_MATCH,
>                                       $this->getPrefixedTableName(self::COMPANIES_TABLE)
>                               )
>                       );
>               }
EOF

Or if you’d prefer to patch manually:

Install an editor:

apt install nano

And add a check for the index before attempting to drop it:

if($schema->getTable($this->getPrefixedTableName(self::COMPANIES_TABLE))->hasIndex(self::INDEX_COMPANY_MATCH))
{
    // Original code around line 58
	$this->addSql(
		sprintf(
			$dropIndexQuery,
			self::INDEX_COMPANY_MATCH,
			$this->getPrefixedTableName(self::COMPANIES_TABLE)
		)
	);
}

That solved that first issue. Some people reported flagging it as migrated already. Since I attempted flagging all as migrated first and it did not work I was concerned about schema consistency.

Version20211209022550 - Failing due to roles table not existing.

This took a little more work. I inspected the migration and noticed that this migration was using Doctrine to get the Model instead of the table directly. It seems that process doesn’t apply the table prefix. I’m not sure if there is another setting that could be changed but my solution was to remove the table prefix entirely and update my configuration.

Shell into the container again (see previous patch) and modify the config:

nano /var/www/html/config/local.php

Set:

'db_table_prefix' => ''

Save and exit the shell.

Now connect to your database directly. This will vary depending on your set up, but for example:

mysql -h 127.0.0.1 -P 3306 -u root -p

Enter your password.

Set your database, e.g.

use mautic;

Now rename all tables to remove the prefix you had before. In my case I used mautic so all of my tables were mauticsomething which needed to be changed to something

Depending on your version you may have a different list of tables. I recommend running show tables; to get the full list.

For each table you’ll need to:

ALTER TABLE mauticsomething RENAME TO something;

For my version it was the following:

ALTER TABLE mauticasset_downloads RENAME TO asset_downloads;
ALTER TABLE mauticassets RENAME TO assets;
ALTER TABLE mauticaudit_log RENAME TO audit_log;
ALTER TABLE mauticbundle_grapesjsbuilder RENAME TO bundle_grapesjsbuilder;
ALTER TABLE mauticcache_items RENAME TO cache_items;
ALTER TABLE mauticcampaign_events RENAME TO campaign_events;
ALTER TABLE mauticcampaign_form_xref RENAME TO campaign_form_xref;
ALTER TABLE mauticcampaign_lead_event_failed_log RENAME TO campaign_lead_event_failed_log;
ALTER TABLE mauticcampaign_lead_event_log RENAME TO campaign_lead_event_log;
ALTER TABLE mauticcampaign_leadlist_xref RENAME TO campaign_leadlist_xref;
ALTER TABLE mauticcampaign_leads RENAME TO campaign_leads;
ALTER TABLE mauticcampaign_summary RENAME TO campaign_summary;
ALTER TABLE mauticcampaigns RENAME TO campaigns;
ALTER TABLE mauticcategories RENAME TO categories;
ALTER TABLE mauticchannel_url_trackables RENAME TO channel_url_trackables;
ALTER TABLE mauticcompanies RENAME TO companies;
ALTER TABLE mauticcompanies_leads RENAME TO companies_leads;
ALTER TABLE mauticcontact_export_scheduler RENAME TO contact_export_scheduler;
ALTER TABLE mauticcontact_merge_records RENAME TO contact_merge_records;
ALTER TABLE mauticdynamic_content RENAME TO dynamic_content;
ALTER TABLE mauticdynamic_content_lead_data RENAME TO dynamic_content_lead_data;
ALTER TABLE mauticdynamic_content_stats RENAME TO dynamic_content_stats;
ALTER TABLE mauticemail_assets_xref RENAME TO email_assets_xref;
ALTER TABLE mauticemail_copies RENAME TO email_copies;
ALTER TABLE mauticemail_list_excluded RENAME TO email_list_excluded;
ALTER TABLE mauticemail_list_xref RENAME TO email_list_xref;
ALTER TABLE mauticemail_stat_replies RENAME TO email_stat_replies;
ALTER TABLE mauticemail_stats RENAME TO email_stats;
ALTER TABLE mauticemail_stats_devices RENAME TO email_stats_devices;
ALTER TABLE mauticemails RENAME TO emails;
ALTER TABLE mauticemails_draft RENAME TO emails_draft;
ALTER TABLE mauticfocus RENAME TO focus;
ALTER TABLE mauticfocus_stats RENAME TO focus_stats;
ALTER TABLE mauticform_actions RENAME TO form_actions;
ALTER TABLE mauticform_fields RENAME TO form_fields;
ALTER TABLE mauticform_submissions RENAME TO form_submissions;
ALTER TABLE mauticforms RENAME TO forms;
ALTER TABLE mauticimports RENAME TO imports;
ALTER TABLE mauticintegration_entity RENAME TO integration_entity;
ALTER TABLE mauticip_addresses RENAME TO ip_addresses;
ALTER TABLE mauticlead_categories RENAME TO lead_categories;
ALTER TABLE mauticlead_companies_change_log RENAME TO lead_companies_change_log;
ALTER TABLE mauticlead_devices RENAME TO lead_devices;
ALTER TABLE mauticlead_donotcontact RENAME TO lead_donotcontact;
ALTER TABLE mauticlead_event_log RENAME TO lead_event_log;
ALTER TABLE mauticlead_fields RENAME TO lead_fields;
ALTER TABLE mauticlead_frequencyrules RENAME TO lead_frequencyrules;
ALTER TABLE mauticlead_ips_xref RENAME TO lead_ips_xref;
ALTER TABLE mauticlead_lists RENAME TO lead_lists;
ALTER TABLE mauticlead_lists_leads RENAME TO lead_lists_leads;
ALTER TABLE mauticlead_notes RENAME TO lead_notes;
ALTER TABLE mauticlead_points_change_log RENAME TO lead_points_change_log;
ALTER TABLE mauticlead_stages_change_log RENAME TO lead_stages_change_log;
ALTER TABLE mauticlead_tags RENAME TO lead_tags;
ALTER TABLE mauticlead_tags_xref RENAME TO lead_tags_xref;
ALTER TABLE mauticlead_utmtags RENAME TO lead_utmtags;
ALTER TABLE mauticleads RENAME TO leads;
ALTER TABLE mauticmessage_channels RENAME TO message_channels;
ALTER TABLE mauticmessage_queue RENAME TO message_queue;
ALTER TABLE mauticmessages RENAME TO messages;
ALTER TABLE mauticmigrations RENAME TO migrations;
ALTER TABLE mauticmonitor_post_count RENAME TO monitor_post_count;
ALTER TABLE mauticmonitoring RENAME TO monitoring;
ALTER TABLE mauticmonitoring_leads RENAME TO monitoring_leads;
ALTER TABLE mauticnotifications RENAME TO notifications;
ALTER TABLE mauticoauth2_accesstokens RENAME TO oauth2_accesstokens;
ALTER TABLE mauticoauth2_authcodes RENAME TO oauth2_authcodes;
ALTER TABLE mauticoauth2_clients RENAME TO oauth2_clients;
ALTER TABLE mauticoauth2_refreshtokens RENAME TO oauth2_refreshtokens;
ALTER TABLE mauticoauth2_user_client_xref RENAME TO oauth2_user_client_xref;
ALTER TABLE mauticpage_hits RENAME TO page_hits;
ALTER TABLE mauticpage_redirects RENAME TO page_redirects;
ALTER TABLE mauticpages RENAME TO pages;
ALTER TABLE mauticpermissions RENAME TO permissions;
ALTER TABLE mauticplugin_integration_settings RENAME TO plugin_integration_settings;
ALTER TABLE mauticplugins RENAME TO plugins;
ALTER TABLE mauticpoint_group_contact_score RENAME TO point_group_contact_score;
ALTER TABLE mauticpoint_groups RENAME TO point_groups;
ALTER TABLE mauticpoint_lead_action_log RENAME TO point_lead_action_log;
ALTER TABLE mauticpoint_lead_event_log RENAME TO point_lead_event_log;
ALTER TABLE mauticpoint_trigger_events RENAME TO point_trigger_events;
ALTER TABLE mauticpoint_triggers RENAME TO point_triggers;
ALTER TABLE mauticpoints RENAME TO points;
ALTER TABLE mauticpush_ids RENAME TO push_ids;
ALTER TABLE mauticpush_notification_list_xref RENAME TO push_notification_list_xref;
ALTER TABLE mauticpush_notification_stats RENAME TO push_notification_stats;
ALTER TABLE mauticpush_notifications RENAME TO push_notifications;
ALTER TABLE mauticreports RENAME TO reports;
ALTER TABLE mauticreports_schedulers RENAME TO reports_schedulers;
ALTER TABLE mauticroles RENAME TO roles;
ALTER TABLE mauticsaml_id_entry RENAME TO saml_id_entry;
ALTER TABLE mauticsms_message_list_xref RENAME TO sms_message_list_xref;
ALTER TABLE mauticsms_message_stats RENAME TO sms_message_stats;
ALTER TABLE mauticsms_messages RENAME TO sms_messages;
ALTER TABLE mauticstage_lead_action_log RENAME TO stage_lead_action_log;
ALTER TABLE mauticstages RENAME TO stages;
ALTER TABLE mauticsync_object_field_change_report RENAME TO sync_object_field_change_report;
ALTER TABLE mauticsync_object_mapping RENAME TO sync_object_mapping;
ALTER TABLE mautictweet_stats RENAME TO tweet_stats;
ALTER TABLE mautictweets RENAME TO tweets;
ALTER TABLE mauticuser_tokens RENAME TO user_tokens;
ALTER TABLE mauticusers RENAME TO users;
ALTER TABLE mauticvideo_hits RENAME TO video_hits;
ALTER TABLE mauticwebhook_events RENAME TO webhook_events;
ALTER TABLE mauticwebhook_logs RENAME TO webhook_logs;
ALTER TABLE mauticwebhook_queue RENAME TO webhook_queue;
ALTER TABLE mauticwebhooks RENAME TO webhooks;
ALTER TABLE mauticwidgets RENAME TO widgets;

Upon success I quit and restarted my container.

All migrations passed after that and I was able to log back it without resetting my installation again.

Final thoughts

I do think it is unfortunate that this hasn’t been officially fixed. I do understand trying to cover all use cases across multiple major releases in all environments is challenging, but this seems very entry level. It is so easy to reproduce. i.e. fresh install + restart container.

I haven’t tested version 7 at all, but I’m not sure if I’ll be sticking with Mautic long term due to some of these sorts of issues and scalability challenges due to it’s architecture.

Hopefully that helps a few people.

1 Like

Hello mcpatcher,

Thanks for your hard work in identifying the root cause of the M6.x migration errors. I’ll try your solution on a test instance shortly and will report back with the results.

At this point I have very little confidence in the reliability of the upgrade process. I’ve stopped performing Mautic upgrades altogether and instead retrofit later bug fixes into my current version, as this remains the safest way to protect the valuable data in the database.

Across this post and others, I’ve highlighted a recurring concern: the Mautic development team is simultaneously upgrading Symfony, delivering minor M6 fixes, and building out new features for the upcoming M7 release. They’re also actively looking to hire developers to add even more new features. Yet it’s clear that testing is not a high priority—otherwise these longstanding issues would have been addressed.

The core problem is that upgrade-related issues are consistently overlooked. The team continues forward with new development despite the fact that upgrading from one Mautic version to another remains unreliable. This isn’t simply a matter of limited time or resources; it reflects a lack of focus and will to prioritise and resolve these fundamental problems that affect the entire community.

I strongly encourage the development team to refocus their attention on ensuring the current features and upgrade paths work reliably before investing further effort into new functionality, Symfony upgrades, or other major changes. A stable foundation will benefit everyone far more than additional features built on top of unresolved issues.

Thanks.

1 Like