Skip to content

Fix cache.delete misuse in messages.update (PrismaClientValidationError crash-loop) #1

@wahyuwidgetworks

Description

@wahyuwidgetworks

Summary

PrismaClientValidationError: Invalid this.cache.delete() is raised in messages.update (stack at /evolution/dist/main.js:227:33183). The code calls cache.delete with a Prisma-style payload instead of a cache key, causing crash loops and dropped Chatwoot sync.

Impact

Likely Root Cause

cache.delete invoked with {instanceId, keyId, Message: {...}} from messages.update; cache expects a string key.

Proposed Fix

  1. In messages.update, derive cache key (e.g., keyId/remoteJid composite) and pass that to cache.delete.
  2. Wrap delete + downstream sync in try/catch to prevent fatal rejection.
  3. (Optional) Feature flag: if set, skip cache.delete on messages.update to stay merge-friendly until upstream fixes.

Evidence

  • Sentry evolution-prod issue EVOLUTION-PROD-3, last seen 2025-12-01T05:02:41Z, culprit POST /chatwoot/webhook/:instanceName.
  • Azure logs: 984 PrismaClientValidationError entries Dec 1 (00:12Z–05:00Z).
  • PENDING/interactiveMessage traffic correlates with the crash loop.

Acceptance

  • No PrismaClientValidationError for cache.delete in messages.update under ad auto-replies, PENDING greetings, reactions/media updates.
  • Messages sync to Chatwoot/Prospek resumes; no crash-loop on webhook.
  • Feature flag documented (if used).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions