Add guide for migrating Sidekiq job queues to Standalone Activities - #5202
Add guide for migrating Sidekiq job queues to Standalone Activities#5202brianmacdonald-temporal wants to merge 2 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📖 Docs PR preview links
|
There was a problem hiding this comment.
Pull request overview
Adds a Ruby migration guide for converting Sidekiq jobs into Temporal Standalone Activities.
Changes:
- Adds the Sidekiq migration tutorial.
- Adds the guide to sidebar navigation.
- Adds a Ruby migration card to the Guides grid.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
docs/guides/sidekiq-to-standalone-activity.mdx |
Adds the migration guide. |
sidebars.js |
Adds sidebar navigation. |
src/components/GuidesGrid/guides-data.json |
Adds the guide card. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| id: sidekiq-to-standalone-activity | ||
| title: Migrate a Sidekiq job queue to a Temporal Standalone Activity | ||
| sidebar_label: Migrate from Sidekiq | ||
| description: Migrate Sidekiq background jobs to a Temporal Standalone Activity. |
| - The Temporal CLI, version 1.7.0 or higher (installed in Step 2). | ||
| - An existing Sidekiq job you want to migrate, or the sample job shown in Step 4 if you are following along from scratch. | ||
|
|
||
| ## Step 1: Set up your project directory |
| keywords: | ||
| - sidekiq | ||
| - standalone activities | ||
| - ruby | ||
| - migration | ||
| - background jobs | ||
| - temporal |
|
|
||
| ## Conclusion | ||
|
|
||
| In this tutorial, you migrated a Sidekiq job to a Temporal Standalone Activity. You converted the job into an Activity, ran a Worker to execute it, started it fire-and-forget in place of `perform_async`, retrieved a return value that Sidekiq could never give you, replaced `sidekiq_options retry:` with a Retry Policy, and inspected your Activities in place of the Sidekiq Web UI — all without writing a single Workflow. Your jobs now survive Worker crashes, retry on well-defined policies, and remain queryable through the client and Web UI. |
chris-olszewski
left a comment
chris-olszewski
left a comment
There was a problem hiding this comment.
Overall looks good to me. I do think keeping the sidekiq / activity definition as close as possible will help illustrate how straightforward this migration is.
Also passed this onto @GregoryTravis who implemented SAA in Ruby for additional 👀
|
|
||
| Before you begin, you will need the following: | ||
|
|
||
| - Ruby 3.2 or higher installed on your machine (3.3 or higher is recommended, since the Worker can then run on fibers). |
There was a problem hiding this comment.
SAA support was only added to versions of the Ruby SDK that require 3.3 or higher
| user = get_user(input["user_id"]) | ||
| deliver_email(user.email, "Welcome!") | ||
| "sent to #{user.email}" |
There was a problem hiding this comment.
I find it a little odd that the activity definition doesn't match the sidekiq job. It gives the appearance of SAA needing to be handled in a special manner. Maybe having shared get_user/deliver_email helpers between the sidekiq job and activity to show that they use the same exact logic.
|
|
||
| # --- Mock helpers ------------------------------------------------------- | ||
| # Replace these with your real user lookup and mailer when you adapt this. | ||
| def get_user(user_id) |
There was a problem hiding this comment.
I agree with what @chris-olszewski said above -- perhaps have a single class that incorporates the functions below as methods, and include it in both code samples, so the user could actually copy + paste the whole example and see it run.
| # my_activity.rb (excerpt) | ||
| require "temporalio/error" | ||
|
|
||
| def execute(input) |
There was a problem hiding this comment.
| def execute(input) | |
| # ... | |
| def execute(input) |
Indent the method so it matches the full source from before.
|
|
||
| def execute(input) | ||
| user = get_user(input["user_id"]) | ||
| raise Temporalio::Error::ApplicationError.new( |
There was a problem hiding this comment.
since get_user() (above) always returns a value, and since you say that the mock deliver_email will throw, I think you can leave this out.
What does this PR do?
Adds a Ruby guide, Migrate a Sidekiq job queue to a Temporal Standalone Activity, that walks through converting a Sidekiq job into a Standalone Activity:
sidekiqprocess, Redis,perform_async,sidekiq_options retry:, Web UI) onto their Temporal equivalentsperform_asyncwithclient.start_activity(), and adds a return value viaclient.execute_activity()— something Sidekiq's fire-and-forget model can't providesidekiq_options retry: Nto a Retry Policy (with the total-attempts vs. retries adjustment:retry: 5->max_attempts: 6)client.list_activities()andclient.count_activities()in place of the Sidekiq Web UIAlso links the page from the Guides sidebar and adds a card to the Guides landing-page grid under the existing
Migrationtag.Notes to reviewers
Opened as a draft: the guide documents Standalone Activities, which are
publicPreviewinsrc/constants/featureReleaseTypes.js.All Temporal doc links are relative to satisfy
Temporal.RelativeLinks. Sidekiq-specific external links (sidekiq.org) remain absolute.Two review conventions from #5135 are already applied: core identifiers use
Id(Activity Id, Run Id) with generic "user identifier", and product name is "Temporal Service".