没有不值得去解决的问题,也没有不值得去学习的技术!

Troubleshooting Unexecuted View Files During Queue Processing in Laravel 6

Since the issue could not be reproduced in the testing environment, I finally decided to simulate the production environment's deployment method as closely as possible. Scaling from a single machine to a cluster, in Rancher's workload, I clicked the + on the right side of the Pod available replicas count to add a Pod. I attempted to reproduce this defect

1. Reference: In Laravel 6, during queue execution, every task executes View::addLocation($location);, however, every task only takes the $location from the first task . But I found that the issue still persisted in the production environment. During queue execution, some view files were not executed (“setting_migrations”:[]). See Figure 1

During queue execution, some view files were not executed ("setting_migrations":[])
Figure 1
SQL

INSERT INTO "" ("source_db", "store_name", "id", "theme_installation_id", "theme_installation_version_preset_id", "from_version", "to_version", "processing", "processing_failed", "step", "failed_message", "extra", "created_at", "updated_at") VALUES ('aws_db12', 'buglcexk30', 5, 5, 5, 'v2.11.1', 'v3.4.0', 0, 0, 7, '', '{"setting_migrations":[],"theme_download_paths":{"zip_path":"/theme_downloads/2023/11/07/1699423025.8743.1229090882.zip","destination":"/theme_downloads/2023/11/07/1699423025.8743.1229090882"}}', '2023-11-08 05:57:02', '2023-11-08 05:57:13');
INSERT INTO "" ("source_db", "store_name", "id", "theme_installation_id", "theme_installation_version_preset_id", "from_version", "to_version", "processing", "processing_failed", "step", "failed_message", "extra", "created_at", "updated_at") VALUES ('aws_db18', 'carver10', 7, 7, 7, 'v2.11.1', 'v3.4.0', 0, 0, 7, '', '{"setting_migrations":[{"file":"v3.0.0/migrate_product_detail.php","exec_at":"2023-11-08 05:57:11"},{"file":"2023_07_11_10_custom_mobile_layout/migrate_product_detail.php","exec_at":"2023-11-08 05:57:11"}],"theme_download_paths":{"zip_path":"/theme_downloads/2023/11/07/1699423022.7951.958836417.zip","destination":"/theme_downloads/2023/11/07/1699423022.7951.958836417"}}', '2023-11-08 05:57:01', '2023-11-08 05:57:11');
INSERT INTO "" ("source_db", "store_name", "id", "theme_installation_id", "theme_installation_version_preset_id", "from_version", "to_version", "processing", "processing_failed", "step", "failed_message", "extra", "created_at", "updated_at") VALUES ('aws_db3', 'cisfioadre59', 8, 8, 8, 'v2.11.1', 'v3.4.0', 0, 0, 7, '', '{"setting_migrations":[],"theme_download_paths":{"zip_path":"/theme_downloads/2023/11/07/1699423022.7315.1637916782.zip","destination":"/theme_downloads/2023/11/07/1699423022.7315.1637916782"}}', '2023-11-08 05:57:01', '2023-11-08 05:57:11');

2. Since the issue could not be reproduced in the testing environment, I finally decided to simulate the production environment’s deployment method as closely as possible. Scaling from a single machine to a cluster, in Rancher’s workload, I clicked the + on the right side of the Pod available replicas count to add a Pod. I attempted to reproduce this defect. See Figure 2

Since the issue could not be reproduced in the testing environment, I finally decided to simulate the production environment's deployment method as closely as possible. Scaling from a single machine to a cluster, in Rancher's workload, I clicked the + on the right side of the Pod available replicas count to add a Pod. I attempted to reproduce this defect
Figure 2

3. Finally, I found that the cause was the queue server running in cluster mode. In cluster mode, certain dependencies between queue tasks were broken. Let me give an example: if the InstallThemeToDb queue is executed on machine A, then the decompressed theme package files exist on that machine. However, after the InstallThemeToDb queue finishes executing, it triggers the execution of the next queue, MigrateThemeSettings, but this queue might execute on machine B. At this point, the execution of this queue depends on the previously decompressed theme package files, but they do not exist on machine B. This consequently causes the theme migration files to not be executed.

4. There are now three solutions:
(1) Merge the 2 Jobs into 1;
(2) Find a way to force the two jobs to execute on the same machine;
(3) Different machines share a single storage, and all decompressed theme package files are placed on the shared storage. This solution requires ensuring there is no time delay;

5. I finally decided to adopt the second solution: finding a way to force the two jobs to execute on the same machine. If you want to execute a queue task immediately (synchronously), you can use the dispatchNow method. When using this method, the queue task will not be queued and will run immediately in the current process.

PHP

MigrateThemeSettings::dispatchNow($this->themeInstallationTask);

6. When an exception is thrown in the MigrateThemeSettings queue, the failed method in MigrateThemeSettings is not executed; instead, the failed method in InstallThemeToDb is executed. This matches expectations. See Figure 3

When an exception is thrown in the MigrateThemeSettings queue, the failed method in MigrateThemeSettings is not executed; instead, the failed method in InstallThemeToDb is executed. This matches expectations
Figure 3

7. When searching for the decompressed theme package files in the MigrateThemeSettings queue, the situation where they cannot be found no longer occurs, which matches expectations.

关于作者 · 持续学习与技术实践

我是一名拥有 15 年以上开发经验的技术从业者,自 2013 年起持续运营个人技术博客,记录工作与个人项目中遇到的真实问题,以及解决问题过程中的探索、实践和思考。

除了技术写作,我也在持续开发和维护自己的独立项目,探索新技术和新工具在实际场景中的应用。我始终相信,没有不值得去解决的问题,也没有不值得去学习的技术。

如果这篇文章对你有所帮助,欢迎浏览博客中的其他文章,也欢迎交流技术经验与想法。

关于我  ·  GitHub  ·  邮件联系