fix(message-templates): WABA-wide template status lookup + channel_id error key (EVO-1717)

[daniloleonecarneiro]

Summary

Non-blocking follow-up to the EVO-1232 [6.3] review (PR #132, already merged). Addresses the findings verified against the merged code:

• 🟡 [Medium] WABA multi-channel status webhook no-op. handle_message_template_status_update resolved the template via the single .first channel returned by find_channel_by_waba_id. Meta's template id (metadata['external_id']) is per-WABA, but a WABA can host multiple whatsapp_cloud channels — so a template living on a sibling channel had its APPROVED/REJECTED status silently dropped. New private find_template_for_waba(waba_id, external_id) resolves the template across every channel of the WABA. The update_columns write and rescue envelope are unchanged. (1-phone-per-WABA deploys — the common community case — were unaffected.)
• 🔵 [Low] Validation error key. The WhatsApp Cloud channel validations moved from :channel to :channel_id, so the JSON error key / frontend field binding matches the 6.3 AC. Server-side blast radius verified empty (only the model + its spec read the key; InboxesController uses an independent string).
• 🔵 [Low] Inbox-scoped route note. Already delivered by EVO-1716 (flat /api/v1/message_templates, routes.rb:162) — verified, no code change.

Test plan

• spec/jobs/webhooks/whatsapp_events_job_spec.rb — new multi-channel WABA group: a deterministic regression guard exercising find_template_for_waba directly (independent of which channel is .first), a cross-WABA negative, a blank-WABA-id guard, an end-to-end perform, and an update_columns-skips-validation case on a model-invalid record.
• spec/models/message_template_spec.rb — the three error assertions flipped to errors[:channel_id].
• spec/jobs/sync_message_template_with_whatsapp_cloud_job_spec.rb — the writeback example reworked to mirror prod's find_or_initialize_by(channel:, name:, language:) persistence (persist + reload) instead of mutating the in-memory instance, which gave false confidence.
• 38 examples, 0 failures. RuboCop clean on touched production files.

Notas

• Merge ordering: touches whatsapp_events_job.rb — coordinate with 7.4a (disjoint case branches, merge-conflict risk only, no logic interaction).
• The :channel → :channel_id rename changes the error key any client could read; frontend handling is tracked under 6.4.
• Scope intentionally narrow: find_channel_by_waba_id still returns .first for channel resolution (other handlers act on a single channel by design) — only the template lookup is broadened.

[sourcery-ai]

Sorry @daniloleonecarneiro, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[dpaes]

Reviewed — approved ✅

Follow-up to the EVO-1232 [6.3] review; both documented fixes verified against the real code at the head ref. CRM-community runs no RSpec in CI, so I traced the specs by hand rather than trusting the self-reported green.

• Medium — WABA multi-channel status webhook no-op: fixed. find_template_for_waba (whatsapp_events_job.rb:138-159) resolves the template across every whatsapp_cloud channel sharing the waba_id (provider_config ->> 'waba_id' OR business_account_id, then MessageTemplate.where(channel_type: 'Channel::Whatsapp', channel_id: channel_ids).find_by("metadata ->> 'external_id' = ?")), and handle_message_template_status_update no longer scopes to the .first channel. The silent return for a template living on a sibling channel is closed. The new "multi-channel WABA" spec group is a genuine regression guard (sibling-channel resolution, cross-WABA negative, blank-WABA guard, end-to-end perform).
• Low — error key: fixed. message_template.rb:236-240 now uses :channel_id for both validations; repo-wide grep shows no remaining errors.add(:channel, / errors[:channel] reader, so the rename is complete and breaks nothing server-side.

Non-blocking (no change required here):

• metadata ->> 'external_id' has no GIN/expression index, but the channel_id IN (...) filter is indexed so the JSON scan is confined to the WABA's templates — same property as the pre-existing single-channel query, fine at community scale.
• The :channel → :channel_id error-key rename is a client-facing contract change; the matching frontend field binding is tracked under 6.4 — worth confirming 6.4 ships so the user-facing benefit lands.

Merge-order note: this touches whatsapp_events_job.rb; the 7.4a work is documented as disjoint-case but merge-adjacent. Checked the open PRs — the only other one near that area (#124) touches a different file, so there's no live conflict.