Skip to content

dtoflow-migration-helper

Cloud Run / CQS queue name: dtoflow-migration-helper Tech stack: Quarkus (Java), Gradle Status: Transitional — to be decommissioned after PLT-2484 migration completes

dtoflow-migration-helper is a temporary bridge service introduced during the PLT-2484 refactor of the link and ESL image DTOs. It maintains bidirectional synchronisation between the old and new DTO versions so that old producers and new consumers (and vice versa) remain compatible during the migration window. Once all producers have been updated to write the new DTO versions and all consumers have been updated to read them, this service becomes redundant and will be removed.

DTO Ownership

dtoflow-migration-helper writes to both old and new DTO versions as part of its bridge work, but it does not own any DTO in the architectural sense — it is a conduit, not an authoritative source.

CQS Subscriptions and Bridges

The service operates three independent bidirectional sync bridges:

Bridge 1: link.v1 ↔ link.v2

Subscription Action
link.v1 When a link.v1 record is written, translate and upsert the equivalent link.v2 record; when link.v1 is deleted, delete link.v2
link.v2 When a link.v2 record is written, translate and upsert the equivalent link.v1 record; when link.v2 is deleted, delete link.v1

link.v2 restructured the link DTO to support multi-item ESLs and a cleaner separation of ESL hardware reference from item assignment. The bridge allows services still writing link.v1 (e.g., Pricer Server legacy path) to coexist with services that have been updated to consume link.v2 (e.g., ecclink-projector).

Subscription Action
designerlink Translate and write the equivalent studiolink record
studiolink Translate and write the equivalent designerlink record

The Studio design tool previously used designerlink to record which Studio template was assigned to an ESL. The new name is studiolink. This bridge keeps both representations consistent during the transition period while Studio and the rest of the platform are updated independently.

Bridge 3: renderedimage ↔ eslimage / studioeslimage

Subscription Action
renderedimage.v1 Translate and write the equivalent studioeslimage.v1 (the Studio renderer's output in the new naming scheme)
studioeslimage.v1 Translate and write the equivalent renderedimage.v1 so legacy consumers (e.g., old dtoflow-transmission queue config) continue to receive updates

renderedimage.v1 was the original single-renderer output DTO. PLT-2484 split the image pipeline into two renderer tracks (studioeslimage.v1 for Studio, ecceslimage.v1 for ECC), merged by eslimage-merger into eslimage.v1. The bridge ensures that services still reading renderedimage.v1 (queued under the legacy pricer-server CQS queue entry) continue to work while the transmission queue is migrated.

Processing Logic

All three bridges follow the same pattern:

  1. Receive a CQS notification for the source DTO type.
  2. Read the current value of the source DTO from DtoFlow.
  3. If present: translate to the target DTO schema (field mapping; the two sides of each bridge carry equivalent data, just differently shaped).
  4. Write the translated record to the target DTO type with the same SLA timestamp.
  5. If absent (deleted): delete the corresponding target DTO record.

Loops are prevented by checking the write origin before acting (or by the fact that each bridge leg has a distinct DTO type as trigger, so a write to link.v2 triggered by a link.v1 event does not re-trigger the link.v1 subscription with a circular update).

Decommission plan

dtoflow-migration-helper is removed in two stages:

  1. Bridge shutdown: Once all producers of a given old DTO have been migrated to write the new version, and all consumers have been migrated to read the new version, the corresponding bridge in dtoflow-migration-helper is disabled.
  2. Service removal: Once all three bridges are shut down, the service is deprovisioned.

The legacy CQS queue entries referencing old DTO types (e.g., renderedimage.v1 in the pricer-server queue, link.v1 in the link-registry queue) are also cleaned up at this point.

  • ecclink-projector — consumes link.v2; benefits from Bridge 1 while Pricer Server still writes link.v1
  • eslimage-merger — consumes studioeslimage.v1; benefits from Bridge 3 while legacy Studio still writes renderedimage.v1
  • dtoflow-transmission — historically consumed renderedimage.v1; Bridge 3 keeps it working during migration to eslimage.v1