Queues and processors

This page maps queue declarations and consumers in axelites/menzzo-meduse at 5d3de6cb63b976aaeef739a8a7f288c4b46509ad. It is a source inventory. The effective queue connection, worker processes, and current job state were not inspected. For the end-to-end connector handoffs around these jobs, see the Meduse workflow map.

Three different processing paths

Path	What starts it	Consumer	State it owns
Scheduler	Framework command schedule:run, which evaluates the kernel and registered module schedule declarations	The scheduled Artisan command handler runs when due	Handler-specific state: database tables, files, FTP, or external service results
Laravel queue	Queue::push, Queue::laterOn, or a queueable dispatch call	A worker using queue:work consumes the configured connection/queue and calls the job handler	Queue-driver jobs and failed-job records; some jobs also update tracked_jobs or file state
Application processor/worklist	A custom Artisan command or code that stores its own work item	For example, shopify:run-scheduled-bulk-operations reads the Mosaikasa shopify_bulk_operations table	Application-specific statuses and file paths, not Laravel's jobs queue

The Logidav FTP pending/processing/complete/failed folders form another file lifecycle. A scheduled command moves files and enqueues a Laravel job; the FTP folders are not queue-driver names.

Exact command names and worker evidence

The checked-in source comment names the scheduler runner schedule:run. It does not define a custom Artisan command named schedule.

The only worker command examples in app/Console/Kernel.php are commented out queue:work entries for export-product-families, export-product-images, export-product-files, process-new-product, export, processing, and default. They are not active workers. The source has no custom signature for queue:run; the repository's custom queue-related command is queue:retry-all. Worker services or commands configured outside this source snapshot remain unknown.

config/queue.php defaults QUEUE_CONNECTION to sync when the environment variable is absent. Thus a queueable dispatch may run inline under that default instead of waiting for a separate worker. If the connection is database, queued rows use the jobs table (retry_after 90 seconds, after_commit false); the Redis connection has its own 9000-second retry-after and commits after transactions. The effective connection and failed-job settings depend on deployment configuration, which was not read.

Queue destinations and active producers

The scan found eight named queues plus the connection's default queue, with 29 distinct job classes in active asynchronous dispatch sites. export and default below include both explicitly named dispatches and jobs dispatched without a queue name; an unnamed dispatch uses the connection's default queue. dispatchSync() calls and commented dispatches are excluded.

Queue	Producer and job classes	Consumer / downstream effect
process-new-product	Scheduled meduse:module:logidav:generate-sync-jobs pushes Modules\Logidav\Jobs\ProcessNewProduct after copying a Logidav FTP file to local processing storage and moving the FTP file to processing; see the new-product handoff.	The job maps/imports new product data, updates its tracked-job record, moves FTP/local files to complete on success or FTP input to failed on exception, rethrows the exception, and then pushes a tenant-specific product export onto export.
processing	Catalog-product API handlers push App\Jobs\UpdateProducts, UpdateProductsExcel, and UpdateProductsNames. Catalog-family handlers push Menzzo or MeublePromo CreateFamily.	These job handlers apply catalog product or family changes. The UpdateProducts handler can enqueue Menzzo ExportProducts on export after the catalog update.
export-product-families	Catalog-family API handler pushes Menzzo or MeublePromo ProductFamiliesProcessor.	The tenant-specific processors export family/catalog data.
export-product-files	UploadProductFileController pushes Menzzo or MeublePromo ProductFilesProcessor.	The tenant-specific processor applies uploaded file associations to products.
export-product-images	ProductImagesUpdated listeners in Menzzo, MeublePromo, and Mosaikasa push each module's ProductImagesProcessor when the event tenant matches.	The module processor handles image export/update work. Mosaikasa's UpdateShopifyProductImagesJob is invoked with dispatchSync() inside its processor, so it is not a separate queue destination.
export-products	ExportProductsEvent listeners in Menzzo and MeublePromo dispatch each module's ExportProducts job to this queue.	The tenant's product export job handles the export. These same job classes are also pushed to the separate export queue from other flows.
export	Product imports/updates and associations push Menzzo or MeublePromo ExportProducts; catalog-attribute API handlers push each tenant's SyncroniseAttributeCatalog; menu API handlers push tenant ExportMenuToJson plus App\Jobs\ExportMenuToCsv; category API pushes Mosaikasa UpdateShopifyMenu; Mosaikasa listeners/manual sync push UpdateShopifyProductNameJob and UpdateShopifyProductAttributesJob; the Asir attribute API schedules App\Jobs\ExportMappingFile with Queue::laterOn('export', 5, ...).	The corresponding jobs export catalog/menu data or update Shopify attributes, names, and mapping files. This is the broad mixed-purpose queue in source.
vimeo-stories	VimeoStoriesController pushes Modules\Menzzo\Jobs\SyncVimeoProductStoriesJob for the requested Vimeo sync.	The job invokes menzzo:vimeo:sync-product-stories, records tracked-job status, uses a one-try setting and per-SKU uniqueness/overlap controls, and rethrows failures.
default	AsirGroupProductAttributeController explicitly pushes App\Jobs\ParseFeatures; unqualified queueable dispatches include Menzzo ProcessAvailabilityUpdateJob from the Logidav stock-sync event listener, Mosaikasa SyncCategoriesFromMeduseToShopifyJob, and MakeUp SyncCategoriesFromMeduseToMakeUpJob. The stock listener selects the Menzzo job; the alternative Mosaikasa dispatch is commented out. See the stock workflow.	These handlers parse product features, update Meduse availability fields, or synchronize Meduse categories to the corresponding Shopify tenant. The active stock-event job updates Meduse catalog state; it does not enqueue the Shopify UpdateAvailabilityJob. The effective queue label for unqualified dispatches follows the active connection configuration.

The producer call sites are in app/Http/Controllers/Api/ and UploadProductFileController.php, the Logidav generator/sync commands, the Menzzo/MeublePromo/Mosaikasa event providers, Mosaikasa availability/job code, and the MakeUp/Mosaikasa category sync code. Their exact repository paths are included in source_refs above.

Queueable classes that are not active asynchronous producers

The source tree contains 36 classes declaring ShouldQueue. Seven do not appear in an active asynchronous dispatch path in this review:

• App\Jobs\MerchantLabels has only commented schedule/dispatch examples.
• App\Jobs\RunConsoleCommandJob has only commented producers, and its handler begins with die('stopped') before the Artisan::call() line.
• Modules\Menzzo\Jobs\ExportMauroProducts is called with dispatchSync() by its console command.
• Modules\Mosaikasa\Jobs\ProcessAvailabilityUpdateJob has a commented event dispatch; the active availability path dispatches Menzzo's job instead.
• Modules\Mosaikasa\Jobs\UpdateProductsAssociationsJob is called with dispatchSync() by its event listener/command.
• Modules\Mosaikasa\Jobs\UpdateShopifyProductImagesJob is called with dispatchSync() inside the Mosaikasa image processor.
• Modules\Mosaikasa\Jobs\UpdateAvailabilityJob is called with dispatchSync() by update:availability; its only queue push is inside the Mosaikasa availability job whose event dispatch is commented out.

Dispatch, consumer, and state flows

View diagram source

flowchart LR
  subgraph LaravelQueue[Laravel queue path]
    Producer[API, event listener, or scheduled command] --> Dispatch[Queue push or queueable dispatch]
    Dispatch --> Driver[Configured queue connection]
    Driver --> Worker[External queue:work worker]
    Worker --> Job[Job handle]
    Job --> Effect[Catalog, files, FTP, Shopify, or Google side effect]
    Job -. failure .-> Failed[Configured failed-job store]
  end

  subgraph LogidavFiles[Logidav product-file path]
    Pending[FTP new-product pending] --> Generator[generate-sync-jobs]
    Generator --> Processing[FTP processing plus local copy and lock]
    Generator --> NewProductQueue[process-new-product queue]
    NewProductQueue --> NewProduct[ProcessNewProduct job]
    NewProduct -->|success| Complete[FTP/local complete]
    NewProduct -->|exception| FailedFile[FTP failed and tracked_jobs failed]
    NewProduct --> ExportQueue[export queue]
  end

  subgraph StockEvent[Logidav stock-event path]
    Stock[Logidav sync-stock-from-logidav] --> AvailabilityEvent[AvailabilityUpdateDetected]
    AvailabilityEvent --> Listener[Mosaikasa EventServiceProvider]
    Listener --> StockQueue[default queue: Menzzo ProcessAvailabilityUpdateJob]
    StockQueue --> CatalogStock[Meduse catalog availability update]
  end

  subgraph ShopifyWorklist[Separate Shopify bulk worklist]
    BulkProducer[Bulk command or ShopifyService] -->|QUEUED row and JSONL path| BulkTable[shopify_bulk_operations]
    BulkTable --> Runner[shopify:run-scheduled-bulk-operations]
    Runner --> Shopify[Staged upload and Shopify mutation]
    Shopify --> Poller[shopify:check-bulk-operations]
    Poller -->|COMPLETED or FAILED| BulkTable
  end

Diagram

The diagram shows source-level connections only. The external queue:work process, runtime queue driver, and successful remote side effects have not been verified.

Failure, retry, and investigation state

State or tool	Source-backed behavior	What it does not prove
jobs	The database queue connection is configured to store jobs in this table; a migration defines it.	That QUEUE_CONNECTION=database is active or that any worker consumes it.
failed_jobs	The queue config defaults the failer to database-uuids and this table, subject to environment overrides. QueueRetryAllCommand reads through the configured failer.	The current number or identity of failed jobs. No database was queried.
queue_monitor	The queue-monitor package is configured to this table; the migration exists. Some jobs use its IsMonitored trait.	Live monitor rows or dashboard health.
tracked_jobs	The TrackedJob model uses this table; Logidav processing/stock/price paths and the Vimeo job write progress/failure status here.	That every queue job is tracked or that stored statuses are current.
Logidav FTP/local file state	The new-product generator/job use pending, processing, complete, and failed; menzzo:retry-failed-files separately returns stale Menzzo export files from processing to pending.	That FTP paths are accessible or files have reached a given state.
shopify_bulk_operations	Bulk commands and ShopifyService store operation type, status, JSONL path, result URL, and error code. The poller updates COMPLETED/FAILED state.	That an external Shopify operation completed successfully.

The custom command queue:retry-all is not a general retry-all implementation in this source: its loop filters to one hard-coded failed-job ID, resets that payload's attempts, and pushes it back to its original connection/queue. The call that removes the original failed record is commented out. Treat the command name/description as inaccurate until corrected by its owner.

The custom Shopify runner also has a state gap: if its JSONL file is missing, it prints that it is marking the row failed and returns without updating the row. Its exception handler logs the error, but does not mark the row failed either. Those paths can leave a row in QUEUED; inspect the stored row and corresponding local-file state before retry decisions.

Evidence gaps

No deployment worker configuration, process list, .env, database, FTP, Merchant Center, or Shopify state was inspected. In particular, the source cannot establish which queue connection is active, which queue names have live workers, whether schedule:run is invoked, or whether a handler's external side effect succeeded. Any production diagnostic or recovery command requires approval for its exact command and target.