E_invoice_tokens_table issue testing database restore

Self-Hosted | v5
1

I run daily mysql dumps for backups and then at least once a month I restore said backups to a test instance to verify. Normally this goes on without an issue however this time I am running into an issue related to e-invoice tokens on a restore. I should note that I do NOT use e-invoices and they are not enabled in Prod.

My process in my test environment:
Import mysql dump from prod to test mysql.
Down all IN containers.
Run a PULL for latest IN version.
UP all containers.

Currently IN is not starting in my test environment due to this error:

2024_10_11_151650_create_e_invoice_tokens_table ................ 2.50ms FAIL
2024-12-17 12:58:05 
2024-12-17 12:58:05 In Connection.php line 825:
2024-12-17 12:58:05                                                                                
2024-12-17 12:58:05   SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'e_invoicing  
2024-12-17 12:58:05   _tokens' already exists (Connection: mysql, SQL: create table `e_invoicing_  
2024-12-17 12:58:05   tokens` (`id` bigint unsigned not null auto_increment primary key, `license  
2024-12-17 12:58:05   ` varchar(64) not null, `token` char(36) not null, `account_key` varchar(64  
2024-12-17 12:58:05   ) not null, `created_at` timestamp null, `updated_at` timestamp null) defau  
2024-12-17 12:58:05   lt character set utf8mb4 collate 'utf8mb4_unicode_ci' engine = InnoDB)       
2024-12-17 12:58:05                                                                                
2024-12-17 12:58:05 
2024-12-17 12:58:05 In Connection.php line 571:
2024-12-17 12:58:05                                                                                
2024-12-17 12:58:05   SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'e_invoicing  
2024-12-17 12:58:05   _tokens' already exists
2

Hi,

It should help to comment out the part of the code that’s failing in 2024_10_11_151650_create_e_invoice_tokens_table and then running php artisan migrate.

You may want to open a discussion on GitHub.

3

Hi hillel!

I am not really sure how/where I would comment that line out? Sorry I did not state this is a docker environment. Typically I have just been able to simply restore the DB and pull the latest images. I might try to drop the database in my test, let IN recreate and try another restore. Just trying to think what might cause this or if it changes my restoration process.

4

@hillel
I seemed to have gotten past this by deleting two tables: e_invoicing_tokens and e_invoicing_logs

It appears I have a fully up to date ver of IN in my test environment using my latest prod IN database backup (not on latest ver of IN). The test instance “seems” to be functioning normally. Not sure if the differences in versions caused this or if future database restores will still require deleting these tables. Again, I do not use e-invoices so I don’t think I need to be concerned with data loss there. Maybe something in the IN startup process can be set to ignore these tables if they already exist instead looping on trying to create them? -Above my knowledge level.

Thanks for your fast reply as always.

@david