Meduse catalog and ASIR mapping handoffs

This page fills the source-review gaps in the older family save, attribute sync, and ASIR mapping notes. Those pages remain historical references. The Magento family and attribute consumers, their exception classes, and focused tests are pinned to axelites/menzzo@6bf5acf477d65bcfd54182549fc9487e110da007; the Logidav and Meduse producer/consumer sources remain pinned to the revisions listed in source_refs. This mixed source evidence does not establish that a deployed FTP handoff, queue worker, or Logidav schedule is active.

Family files

For non-tenant requests, the Menzzo catalog family endpoint queues Modules\Menzzo\Jobs\CreateFamily on the processing queue; the meuble_promo tenant dispatches a separate job. The Menzzo job calls FamilyService::generateCsvFile when the Menzzo connector is enabled. The service writes a comma-delimited file to meduse/connectors/menzzo/family/pending/. The file has a header row and one data row containing meduse_id, name, code, label and image attribute codes, translated labels, and dynamic to_add_attr_*, to_add_attrgroup_*, and to_remove_attr_* fields. (family endpoint, queued job, CSV producer)

Logidav's meduse:family:save first looks in meduse/connectors/menzzo/family/complete/, moves those files to meduse/connectors/logidav/family/pending/, and then processes the Logidav pending folder. It parses CSV and runs menzzo:v2:attribute followed by menzzo:migrate-attribute-set-mapping-from-magento only for a row whose header includes magento_attribute_set_name. A handled exception adds a logidav_obs column and moves the file to failed; earlier command effects are not rolled back by this handler. (Logidav consumer)

Magento supplies the intermediate step. Its SyncFamily consumer attempts to move the family CSV from menzzo/family/pending to processing, updates the Magento attribute set and mappings, adds magento_attribute_set_name when a set is available, and attempts to move the file to complete. If FTP read() returns false, the consumer throws UnableToReadFamilyFileException; the handler logs the failure, but writes magento_obs only when parsed rows exist, so this read-failure path has no annotation. It attempts to move the processing file to failed. If directory setup or listing throws an Exception before a destination path is assigned, the handler logs and rethrows without annotating or moving a file, and the following cache clear is skipped. The handler catches Exception, not every Throwable; FTP move return values are unchecked, so these are attempted transitions rather than proof of file state. This explains the field and directory expected by Logidav; Meduse's initial CSV is not the final Logidav input. The source-level bridge is traced in Magento catalog dependencies, including the failure behavior. The deployed FTP namespace and execution remain unverified. (Magento family consumer, read exception, family failure tests)

Catalog attribute files

On a non-tenant Menzzo attribute create or update, CatalogAttributeController queues SyncroniseAttributeCatalog on the export queue. The job serializes one JSON object in a .txt file and writes it to meduse/connectors/menzzo/export_attributes/pending/. Its fields are attribute_data, attribute_translation, code_option, attribute_option_translate, attribute_group, and idMagento; the producer sets idMagento to an empty string. It records the tracked job as finished after the FTP write and before the database commit. (attribute endpoint, attribute export job)

Logidav's meduse:sync:attributes first moves files from meduse/connectors/menzzo/export_attributes/complete/ to meduse/connectors/logidav/export_attributes/pending/, then moves each Logidav pending file to processing and decodes its JSON. It invokes menzzo:v2:attribute with a generated token, looks up the attribute and option mapping using the file's idMagento, and inserts missing pairs into mz_meduse_product_attributes_mapping and mz_meduse_product_attribute_options_mapping. The decoded attribute_data is not passed to the command invocation in this processing path. (Logidav consumer)

Magento's SyncAttributes supplies the intermediate step: it lists .txt entries under /meduse/connectors/menzzo/export_attributes/pending and processing, checks candidate names with FTP cd(), skips entries where that probe succeeds, and attempts to restore the listing directory. A failed cd() leaves an entry eligible, so source alone does not establish that it is a regular file. If restoring the listing directory fails, the helper closes FTP and throws UnableToRestoreFtpDirectoryException outside the per-file error handler; that directory-probe failure has no menzzo_error or file acknowledgement, and the later normal close/cache-clear calls are skipped. For non-empty file content, the consumer creates or updates the Magento attribute, fills idMagento, calls write() to rewrite the JSON, and attempts to move it to complete; a caught Throwable in the per-file operation adds menzzo_error and attempts a move to failed. The relative and slash-prefixed paths in these repositories still depend on the actual FTP root; no runtime namespace check was performed. See Magento catalog dependencies, the pinned consumer and directory probe, restore exception, and directory-probe tests.

The Logidav command renames a file to complete before its mapping lookup and inserts; if those later steps throw, its catch block still writes and renames using the former processing path. Therefore the complete file state alone does not prove that both mapping tables were updated. On the Meduse side, an exception rolls back the database transaction and marks the tracked job failed, but the FTP write occurs before commit, so a remote file can outlive a failed job record.

ASIR attribute mappings

After the ASIR product-attribute controller saves mapping data, it queues ExportMappingFile five seconds later on the export queue. The job builds a JSON Lines file from ASIR attributes and their Meduse catalog attribute, option, family, and menu associations, then writes the fixed path meduse/connectors/logidav/export-asir-mappings/mapping.jsonl. Each line carries meduse_attribute_code, meduse_attribute_option_code, asir_attribute_label, asir_attribute_option_value, mapping_type, and extra_info. text_mapping and specific_dimension_mapping rows use an empty option-code field. For Custom Asir Category, the Meduse family code goes in meduse_attribute_option_code, while menu category_ids go in extra_info; color-family and material-detail codes go in extra_info, and material-structure codes go in meduse_attribute_option_code. (mapping update trigger, JSONL producer, option and extra-info rules, file fields and destination)

Logidav's menzzo:sync-asir-attribute-mapping-from-meduse reads that same fixed path and parses it line by line as JSON. It creates the temporary table mz_asir_group_attributes_mapping_tmp if needed, truncates it, inserts parsed rows, JSON-encodes array option codes and extra_info, then inserts into mz_asir_group_attributes_mapping only tuples that do not already match all six mapping fields. The command does not move or delete the source file, and this merge does not update or remove existing main-table rows. The command help text names mz_asir_attributes_product_mapping; the SQL and entity identify the actual table as mz_asir_group_attributes_mapping. (Logidav importer, mapped table)

The ASIR producer and consumer agree on the path and field names in the inspected source, so this is a source-visible file contract. The importer is add-only: its anti-join suppresses repeats for identical non-null tuples, while changed or removed source mappings do not replace or delete old main-table rows. The entity allows nullable columns, and SQL equality does not match NULL to NULL, so duplicate suppression for null-containing tuples needs non-production verification. Invalid JSON lines are skipped by the consumer's truthiness check; database and FTP outcomes were not exercised here.

Schedule evidence and non-production checkpoints

The legacy command notes list */5 * * * * and refer to rows in Logidav's historical system-crontab.md. The pinned command classes establish command names and code behavior, not the current server crontab. Meduse's source shows queue dispatches for family and attribute exports, and a five-second delayed queue dispatch for ASIR export; these calls do not prove that a worker is running. Deployment schedule, FTP state changes, queue processing, and destination database results remain unverified.

For non-production validation, use disposable catalog data and isolated FTP/database targets. First compare the actual family and attribute files with the Logidav reader's expected state and schema, including the family header and attribute idMagento; do not treat a moved-to-complete file as success until the intended Logidav mutations are read back. For ASIR, compare the JSONL rows with the imported table, run the same fixture twice (including nullable fields) to check duplicate behavior, and confirm the intended policy for changed or removed mappings. These checkpoints are recommendations only; no application command or environment was run for this page.