Knowns:

• Magento 2.3.5-p1 removes Temando_Shipping.
• References to plugins are cached

For the deployment to complain about that file, it seems like it must be reading from the previous release's cache. Or if Redis is being used, the cache is being shared between the current release and the one in progress.

Possible Culprits:

• Opcache? Opcache likes to hang on to references to old folders
• Redis? is new deployment reading from current release cache
• Something else?

Will add more as I find out...

Update

Successfully just deployed and got around this issue. For me it was Redis cache from the previous deployment interfering with the one in progress. What I ended up doing to get around it:

Pre-Deployment

1. Enabled Maintenance Mode

Manually ssh'd into the production server to enable maintenance mode:

Why?

• Prevent customers/browsers from hitting website and causing redis to fill back up.

php bin/magento maintenance:enable

2. Disabled All Magento Crons

Temporarily commented out Magento cron's

Why?

• Prevent crons from hitting magento / filling redis cache in any way.

crontab -e
// comment out crons in editor and save

3. Flushed Redis

Why?

• To remove cache that is referencing Temando Shipping plugins

Your port numbers may be different

redis-cli -h redis -p 6381 flushall;
redis-cli -h redis -p 6382 flushall;

4. Ensure Cache Not Filling

Our codebase gets synced out to a cluster, so I had to make sure all nodes on the cluster were not serving Magento at all

• Added a die statement at beginning of pub/index.php
• Ran command to sync code to cluster

5. Verify Redis Cache Stays Empty

This was a key part that kept making my deployment fail even after flushing redis.

redis-cli -h redis -p 6381 KEYS '*'

Should show that there is an empty set/list

---

Deployment

1. Run Deployment

Run the deployment

---

Post-Deployment

1. Re-enable Crons

Don't want to forget to re-enable the crons

crontab -e
// uncomment out crons in editor and save