release(chatwoot-adapter): 0.8.0 — recover from a deleted Chatwoot conversation - #56
Merged
Merged
Conversation
…on deleted out of band
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Minor release for the recovery behaviour merged in #45.
Deleting a Chatwoot conversation out of band used to leave the adapter's cached mapping pointing at a dead conversation: every later message from that chat was posted to it, rejected, and retried against the same id until it gave up, so the chat silently stopped reaching Chatwoot. The adapter now drops the stale mapping, rebuilds through its normal path while reusing the existing contact, and re-posts into the fresh conversation; a failed rebuild falls back to the retry queue. Recovery is deliberately skipped while draining the retry queue, since a queued message is already a re-attempt and rebuilding there would mint a conversation per attempt.
Verified against a live OpenWA 0.12.1 host with a connected WhatsApp session and a real Chatwoot instance: a mapped conversation was deleted, posting to it was confirmed rejected, and the next message from that chat caused the adapter to drop the mapping and mint a fresh conversation keeping the same contact — the message was delivered, nothing entered the retry queue, and the plugin reported healthy.
Not exercised live, and stated as such in the changelog: the own-send recovery path and the retry-drain no-recovery path. Both are covered by tests.
testedOpenWAVersionis unchanged at 0.12.1 — the host did not change.