Release 6.4.4-pre2

Release Notes — Cumulocity Dynamic Mapper v6.4.4

August 2026 · Dynamic Mapper

This release adds an AI-generated alternative to code templates when creating Smart
Functions, bundles a connector's connection-lifecycle status transitions into a single
event per connect/disconnect attempt instead of one independent event per status change,
and fixes a bug that left devices permanently unreachable — with repeated error-log
noise — once their auto-created device was deleted from inventory.

---

👤 Customer-Facing Changes

Changes that affect what users see or how the product behaves.

✨ New Features

• Generate Smart Functions with AI instead of a code template #543

  • When creating a new Inbound/Outbound mapping with transformation type Smart Function
    (JavaScript), the "Select Payload Format and Transformation Type" step now offers an
    explicit choice — "Choose Code Template" vs. "Generate with AI" — whenever an AI
    agent is deployed for Smart Functions. The choice defaults to "Generate with AI" when an
    agent is available, falling back to the template dropdown otherwise.
  • Generation is deferred until the Transformation step, where the real source/target
    templates are available, and triggers automatically the first time that step is reached.
  • Fixed a related bug along the way: the auto-triggered generation could send a stale
    default source template to the AI agent instead of the user's just-edited one, because it
    relied on a change-event mirror that didn't fire for all edit paths (e.g. some tree-mode
    interactions). It now reads the live content directly from the JSON editor.

• Open version history and see draft status directly from the Versions list #546

  • The Monitoring → Versions pages (Versions inbound / Versions outbound) now have a
    "Versions" row action that opens the existing version-history drawer for that mapping,
    instead of requiring a detour through the main Mapping grid.
  • Added a "Status" column showing a draft badge for any mapping with unpublished draft
    changes, so pending drafts are visible across the whole list at a glance instead of only
    after opening each mapping individually.

• Connector status log now shows one event per connect/disconnect attempt instead of one per status change #547

  • Every connector status transition (CONNECTING, CONNECTED, DISCONNECTING,
    DISCONNECTED, RETRYING, FAILED) used to be posted as an independent Cumulocity
    event, so a single connect attempt with one retry produced 3–4 unrelated rows in
    Monitoring → Service events and the per-connector Details & logs page, with no
    way to tell which rows belonged together. Each connection-lifecycle session is now
    bundled into a single event that's updated in place as it progresses — the same
    "History of changes" pattern Cumulocity Operations use — with an entry-count badge, an
    "open"/error indicator, and an expandable compact timeline of that session's
    transitions.
  • CONFIGURED (a settle/idle marker, never itself part of a connect/disconnect attempt)
    no longer generates its own event at all — it was showing up as an extra, low-signal
    bundle on every disconnect/reconnect cycle. The connector's live status display is
    unaffected; only the persisted event history changed.
  • Fixed a related bug found while verifying this in production: the MQTT and AMQP
    connectors could report the same physical disconnect twice — once via the explicit
    disconnect call, once via the underlying client library's own disconnected/exception
    listener firing as a side effect of that same call — which showed up as two separate
    sessions instead of one. Every other connector type (Kafka, Pulsar, HTTP, WebHook) was
    checked and found not to have this pattern.

🐛 Bug Fixes

• Deleted devices left the mapper permanently unable to re-create them #544
  • Once a device that the mapper had created implicitly (createNonExistingDevice: true)
    was later deleted from Cumulocity inventory, every subsequent inbound message for the
    same external ID kept resolving to the deleted device's stale internal id — forever. This
    produced a permanent per-message failure loop: repeated 404s from the notification
    subscription API, or 422 Source object does not exist in inventory from
    measurement/event creation, with the device never recreated even though
    createNonExistingDevice was enabled.
  • Root cause: TenantRegistry's external-ID resolution cache had no invalidation path —
    a removeFromExternalIdCache method existed for exactly this purpose but had never
    been wired up to any actual failure path. The mapper's Notification 2.0 stream also
    didn't help: it only reacted to UPDATE events, silently dropping DELETE (and
    CREATE) notifications without evicting anything.
  • Fixed by evicting the stale cache entry as soon as a deletion is discovered — via a real
    inventory lookup, via a Notification 2.0 DELETE event (now handled, with the
    now-pointless subscription torn down), and via the existing 422-retry path in the
    inbound message pipeline (which previously cleared a different, unrelated cache). A
    message for a deleted device's external ID still hits one failure to discover the
    deletion — unavoidable, that's how it's detected — but the very next message now gets a
    freshly created device instead of repeating the same failure indefinitely.
  • Also cleaned up related error-log noise: the same failure was previously logged three
    times, with a full stack trace each time, as it propagated up through nested handlers
    that just rethrew it unchanged. Now logged once, at the point where it's actually
    handled.

---

⚙️ Internal / Implementation Changes

Refactoring, code-quality, and platform maintenance work with no intended change in
customer-visible behavior.

• Added regression coverage for the device-recreation fix #544
  • New unit tests for TenantRegistry's external-ID cache reverse-index/eviction, for
    InventoryCacheEnrichmentService's device-not-found path, and for
    CacheInventoryUpdateClient's Notification 2.0 DELETE handling.
  • New shell integration test
    (test-inbound-implicit-device-recreate-after-delete.sh, registered in the inbound
    suite): create an implicit device, delete it, resend a message for the same external ID,
    and assert a new device is auto-created with a different internal id.

---

Cumulocity Dynamic Mapper · v6.4.4 · August 2026
All releases on GitHub
Full Changelog: v6.4.3...develop