Fix double render in Slack::PuzzlesController when notification fails

[JuanVqz]

Problem

send_message in Slack::ApplicationController called head :unprocessable_entity when rescuing a Slack::Web::Api::Errors::SlackError. This had two issues:

1. Wrong response to Slack — the puzzle was already saved, but Slack was told the request failed (422).
2. Double render — execution returned to Slack::PuzzlesController#create, which then called render json:, raising AbstractController::DoubleRenderError. Same class of bug as Fix double render in ApplicationController auth callbacks #66.

# Before — rendering side effect inside a helper method
def send_message(message, channel_id:)
  SlackClient::Client.instance.chat_postMessage(...)
rescue Slack::Web::Api::Errors::SlackError
  head :unprocessable_entity  # renders, but execution returns to caller
end

# In create — double render!
send_message(...)
render json: { response_action: "update", view: view }, status: :ok

Fix

send_message now logs the error, captures it in Sentry for full context, and returns without rendering. This means:

• No rendering side effects leak into callers
• create always responds 200 to Slack when a puzzle is saved successfully
• The workaround return if performed? is no longer needed

def send_message(message, channel_id:)
  SlackClient::Client.instance.chat_postMessage(...)
rescue Slack::Web::Api::Errors::SlackError => e
  Rails.logger.error "Failed to send Slack message: #{e.message}"
  Sentry.capture_exception(e)
end

Tests

• renders ok when puzzle fails validation — action returns 200 when puzzle doesn't save (no Slack call made)
• renders ok even when Slack notification fails after puzzle is saved — action returns 200 even when send_message fails, confirming notification failure doesn't affect the Slack response

[JuanVqz]

Superseded by #71 which addresses this and three other related bugs with a more robust design.