Reports

This is a common issue with the stancl/tenancy package where migrations run successfully on the first tenant but appear to have "Nothing to migrate" on subsequent tenants. The problem typically stems from the package's internal migration tracking mechanism.

Root Cause

The package uses a migrations table in each tenant database to track which migrations have been run. When you run tenants:migrate, it processes tenants sequentially. After the first tenant completes successfully, the migration is marked as executed in the package's internal state, causing subsequent tenants to skip the migration.

Solution

1. Check Tenant Migration Tables

First, verify that each tenant database has a migrations table and that your new migration files aren't already recorded there:

-- Check tenant_2 and tenant_3 databases
SELECT * FROM migrations WHERE migration LIKE '%orders%' OR migration LIKE '%order_items%';

2. Clear Migration Cache

The package may be caching migration status. Clear the cache:

php artisan tenants:migrate-fresh --force
# WARNING: This will drop all tables and re-run migrations for ALL tenants

For a safer approach, use this sequence:

# Reset migration state for specific tenants
php artisan tenants:run tenant_2 --command "migrate:reset"
php artisan tenants:run tenant_3 --command "migrate:reset"

# Then run migrations again
php artisan tenants:migrate --force

3. Alternative: Run Migrations Per Tenant

Run migrations for each tenant individually to isolate the issue:

php artisan tenants:run tenant_2 --command "migrate --force --path=database/migrations/tenant"
php artisan tenants:run tenant_3 --command "migrate --force --path=database/migrations/tenant"

Also check that the tenant migration path exists and contains your migration files.

4. Check Database Connections

Verify that each tenant has the correct database connection configured in your tenancy setup.

Debugging Steps

Check migration status per tenant:

php artisan tenants:run tenant_2 --command "migrate:status"

Manually inspect each tenant's migrations table:

php artisan tenants:run tenant_2 --command "db:table migrations"

Test with a new migration file to see if the issue persists with fresh migrations.

Prevention

For future migrations, consider using the package's built-in commands that handle this scenario better, or implement a custom migration command that resets the migration state between tenants.

If the issue persists after trying these solutions, there may be a deeper configuration issue with your tenancy setup that requires examining your tenant identification and database connection logic.

// Example of checking tenant connections
$tenants = AppModelsTenant::all();
foreach ($tenants as $tenant) {
    tenancy()->initialize($tenant);
    // Check migration status
    Artisan::call('migrate:status');
    tenancy()->end();
}

Remember to test these solutions in a development environment before applying them to production.

If you need further assistance, please provide the output of php artisan tenants:run tenant_2 --command "migrate:status" and the structure of your tenant databases.

79783869