When a customer responds to a bot's interactive prompt (input_select, input_csat, form, input_email) from the widget, the response shows up in the Chatwoot agent UI but is not reflected in the linked Slack channel — Slack only ever shows the original question. This happens because the widget submits the answer as an UPDATE to the original message (writing `content_attributes.submitted_values` or `submitted_email`), but the Slack hook only listened to `message.created`, so updates were ignored. Closes https://linear.app/chatwoot/issue/PLA-147 ### Preview <img width="1290" height="1106" alt="CleanShot 2026-04-21 at 13 19 19@2x" src="https://github.com/user-attachments/assets/cd2a9d3f-89d3-4e81-9230-5b078e1b7b44" /> ### How to test 1. Connect a web widget inbox to a Slack channel. 2. Trigger each bot message type (input_select, form, input_csat, input_email) in a conversation. 3. Submit responses from the widget. 4. Verify each response now appears in the Slack thread, appended to the original bot question. --------- Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
95 lines
3.9 KiB
Ruby
95 lines
3.9 KiB
Ruby
class HookJob < MutexApplicationJob
|
|
retry_on LockAcquisitionError, wait: 3.seconds, attempts: 3
|
|
|
|
queue_as :medium
|
|
|
|
def perform(hook, event_name, event_data = {})
|
|
return if hook.disabled?
|
|
|
|
case hook.app_id
|
|
when 'slack'
|
|
process_slack_integration(hook, event_name, event_data)
|
|
when 'dialogflow'
|
|
process_dialogflow_integration(hook, event_name, event_data)
|
|
when 'google_translate'
|
|
google_translate_integration(hook, event_name, event_data)
|
|
when 'leadsquared'
|
|
process_leadsquared_integration_with_lock(hook, event_name, event_data)
|
|
end
|
|
rescue StandardError => e
|
|
Rails.logger.error e
|
|
end
|
|
|
|
private
|
|
|
|
def process_slack_integration(hook, event_name, event_data)
|
|
message = event_data[:message]
|
|
|
|
case event_name
|
|
when 'message.created'
|
|
if message.attachments.blank?
|
|
::SendOnSlackJob.perform_later(message, hook)
|
|
else
|
|
::SendOnSlackJob.set(wait: 2.seconds).perform_later(message, hook)
|
|
end
|
|
when 'message.updated'
|
|
# Only interactive bot messages store responses via content_attributes (submitted_values / submitted_email).
|
|
# Skip other content types to avoid unnecessary job enqueues on every message update.
|
|
return unless message.content_type.in?(Integrations::Slack::UpdateSlackMessageService::SUPPORTED_CONTENT_TYPES)
|
|
# Guard against redundant Slack updates when unrelated attributes change (e.g. status)
|
|
# while submitted_values is already present on the message.
|
|
return unless event_data[:previous_changes]&.key?('content_attributes')
|
|
|
|
::UpdateSlackMessageJob.perform_later(message, hook)
|
|
end
|
|
end
|
|
|
|
def process_dialogflow_integration(hook, event_name, event_data)
|
|
return unless ['message.created', 'message.updated'].include?(event_name)
|
|
|
|
Integrations::Dialogflow::ProcessorService.new(event_name: event_name, hook: hook, event_data: event_data).perform
|
|
end
|
|
|
|
def google_translate_integration(hook, event_name, event_data)
|
|
return unless ['message.created'].include?(event_name)
|
|
|
|
message = event_data[:message]
|
|
Integrations::GoogleTranslate::DetectLanguageService.new(hook: hook, message: message).perform
|
|
end
|
|
|
|
def process_leadsquared_integration_with_lock(hook, event_name, event_data)
|
|
# Why do we need a mutex here? glad you asked
|
|
# When a new conversation is created. We get a contact created event, immediately followed by
|
|
# a contact updated event, and then a conversation created event.
|
|
# This all happens within milliseconds of each other.
|
|
# Now each of these subsequent event handlers need to have a leadsquared lead created and the contact to have the ID.
|
|
# If the lead data is not present, we try to search the API and create a new lead if it doesn't exist.
|
|
# This gives us a bad race condition that allows the API to create multiple leads for the same contact.
|
|
#
|
|
# This would have not been a problem if the email and phone number were unique identifiers for contacts at LeadSquared
|
|
# But then this is configurable in the LeadSquared settings, and may or may not be unique.
|
|
valid_event_names = ['contact.updated', 'conversation.created', 'conversation.resolved']
|
|
return unless valid_event_names.include?(event_name)
|
|
return unless hook.feature_allowed?
|
|
|
|
key = format(::Redis::Alfred::CRM_PROCESS_MUTEX, hook_id: hook.id)
|
|
with_lock(key) do
|
|
process_leadsquared_integration(hook, event_name, event_data)
|
|
end
|
|
end
|
|
|
|
def process_leadsquared_integration(hook, event_name, event_data)
|
|
# Process the event with the processor service
|
|
processor = Crm::Leadsquared::ProcessorService.new(hook)
|
|
|
|
case event_name
|
|
when 'contact.updated'
|
|
processor.handle_contact(event_data[:contact])
|
|
when 'conversation.created'
|
|
processor.handle_conversation_created(event_data[:conversation])
|
|
when 'conversation.resolved'
|
|
processor.handle_conversation_resolved(event_data[:conversation])
|
|
end
|
|
end
|
|
end
|