Configuring Solid Cable on Render

Rails 8 added a lot of new features. Solid Cable comes as a drop in replacement to Action Cable and, by default, it uses the database instead of requiring Redis.

I generated a new app (with Postgres), added some tables and turbo streams and then deployed to Render. The deployment failed!

Exited with status 1 while building your code.

This error message wasn’t very clear! But the line of code pointed to a broadcasts_to in my Comment model, so I was pretty sure it was Solid Cable related.

after_create_commit -> { broadcast_before_to "...", target: "...", partial: "..." }

I learned that Solid Cable runs in a separate database, which I assume Render didn’t like. I followed the instructions in the Solid Cable README to configure Solid Cable to work with a single database and I was able to deploy to Render!

1. Copy the contents of db/cable_schema.rb into a normal migration and delete db/cable_schema.rb
2. Remove connects_to from config/cable.yml
3. bin/rails db:migrate

🎉

Markdown footnotes

I forget this all the time.

just do this:

Some text[^1].

Some other text[^2].

The identifier in the square brackets does not have to be numeric[^my_footnote].

[^1]: Some footnote.
[^2]: Other footnote.

[^my_footnote]: This also works fine.

This is not supported in GitHub repository code.

Naming DB indexes

Rails 7 apps have a limit on autogenerated index names of 63 characters.

ArgumentError: Index name
'index_codeblock_submission_on_user_id_and_lesson_id_and_block_id_and_internal_submission_id' on table
'codeblock_submission' is too long; the limit is 63 characters.

To work around this you can choose a name to use instead of the autogenerated one.

update the migration with the name key and value:

    add_index :codeblock_submissions, [:user_id, :lesson_id, :block_id, :internal_submission_id], unique: true, name: "index_codeblock_submissions_on_block_lesson_user_submission"
  end

Source

WSL - Syncing system clock

WSL2 clock sometimes becomes out of sync with native windows clock. This can apparently happen after resuming from sleep/hibernate but not always.

To re-sync run:

sudo hwclock -s

Rails - Extracting controller logic

In situations where one controller action is responsible for a lot, I’ve usually been able to extract the complicated code into a model method or helper. This works fine when the complicated logic has to do with the model instead of it being a 5 branch if statement on how to decide what to show the user.

In those situations some people might say that you hecked up and designed your routen poorly. And maybe they’re right.

Anyway, I was able to turn this complicated controller action:

  def show
    if params.has_key?(:token)
      invite_link = @forum.invite_links.find_by(token: params[:token])
      if invite_link.active?
        if current_user.present? && current_user.is_member_of?(@forum)
          redirect_to forum_posts_path(@forum), alert: "You're already a member of #{@forum.name}."
        elsif current_user.present? && !current_user.is_member_of?(@forum)
          current_user.memberships.create(invite_link: invite_link, forum: @forum)
          redirect_to forum_posts_path(@forum), notice: "You're now a member of #{@forum.name}."
        else
          render "invite_links/sign_up"
        end
      else
        redirect_back_or_to root_path, alert: "Invite link has not been activated."
      end
    else
      redirect_back_or_to root_path, alert: "You don't have access to view that page."
    end
  end

into this:

  def show
    Forums::HandleInviteService.new(@forum, self).process
  end

after realizing that I can just pass the instance of the controller class to a separate Ruby object and then call render, redirect_to, and params on the controller object.

I’m not the biggest fan of service objects but this seemed to work nicely.