Curated
Assess the blast radius before deleting code
You are deciding whether this code is safe to delete. List everything that could still depend on it, including callers in the code given, dynamic dispatch by name, serialised references such as enqueued jobs or stored class names, database columns or migrations, public API surface, and anything reachable from configuration or templates. For each, say how you would verify it before deleting. End with a plain verdict: safe, unsafe, or cannot determine from what was provided. Code: {{code}}
Fill in: The code you want to remove, plus how it is referenced if you already know of any callers.
Known limits: Cannot grep your repository — dynamic references are the ones it will raise as questions rather than facts.
Run evidence
Sandbox run 2026-07-30 · openai/gpt-5-nano
Input fixture
# Candidate for deletion: this worker and its class.
class LegacyDigestWorker
include Sidekiq::Job
sidekiq_options queue: "mailers", retry: 5
def perform(user_id, digest_type = "weekly")
user = User.find_by(id: user_id)
return unless user
DigestMailer.send(digest_type, user).deliver_now
end
end
# Known: nothing in app/ calls LegacyDigestWorker.perform_async directly.
# The scheduler config has an entry keyed "legacy_digest" that was commented out
# three months ago. Sidekiq's retry set currently holds ~400 jobs.
Model output (unedited)
Summary of the code
- LegacyDigestWorker is a Sidekiq worker in the mailers queue.
- It takes a user_id and an optional digest_type (default "weekly"), finds the user, and sends a digest mail via DigestMailer.send(digest_type, user).deliver_now.
What could still depend on it and how to verify before deleting
1) In-code callers (static references)
- What to check
- Any code that calls LegacyDigestWorker.perform_async (or any dynamic dispatch that ends up enqueuing this worker).
- Any references to the class name as a string or symbol (e.g., "LegacyDigestWorker") anywhere that calls perform_async or performs a constantize.
- How to verify
- Full repo search for:
- perform_async calls: rg -n "LegacyDigestWorker\.perform_async" -S
- Any reference to the class name string: rg -n "LegacyDigestWorker" -S
- If found, inspect and determine if those code paths should be migrated or removed along with the worker.
- What if you find references
- If legitimate enqueue points exist, you’ll need a migration plan (e.g., point to a new worker or remove those calls).
2) Dynamic dispatch by name / serialized job payloads in Sidekiq
- What to check
- Sidekiq jobs already enqueued or retried (serialized in Redis) that refer to this class.
- Specifically, items with klass = "LegacyDigestWorker" in RetrySet, ScheduledSet, DeadSet, or any live queues.
- How to verify
- In Rails console or a script:
- require 'sidekiq/api'
- Sidekiq::RetrySet.new.each { |j| puts "retry #{j.jid} #{j.klass}" if j.klass == 'LegacyDigestWorker' }
- Sidekiq::ScheduledSet.new.each { |j| puts "scheduled #{j.jid} #{j.klass}" if j.klass == 'LegacyDigestWorker' }
- Sidekiq::DeadSet.new.each { |j| puts "dead #{j.jid} #{j.klass}" if j.klass == 'LegacyDigestWorker' }
- Sidekiq::Queue.new.each { |j| puts "queue #{j.jid} #{j.klass}" if j.klass == 'LegacyDigestWorker' }
- Alternatively, use the Sidekiq web UI to inspect the Retry, Scheduled, and Dead sets and filter by class.
- What if you find references
- Do not delete yet. Decide whether to:
- Let those jobs run (and complete or fail) before deleting, or
- Requeue/migrate them to a new worker, or
- Remove the enqueue points and then delete the worker.
- If you must delete, you’ll need to purge or migrate those jobs first.
3) Scheduler configuration (configured/delayed runs)
- What to check
- Any Sidekiq schedule entries that reference legacy_digest, even if commented out, or any code that loads a schedule file containing this key.
- The presence of a sidekiq.yml or an initializer that loads a YAML/JSON schedule including a legacy_digest entry.
- How to verify
- Grep for the key across the repo:
- rg -n "legacy_digest" -S
- Inspect config/sidekiq.yml, config/initializers/sidekiq.rb, or any sidekiq-cron/sidekiq-scheduler config files to see if legacy_digest would be loaded or scheduled.
- If there is a scheduled job present in Redis, verify whether that schedule is still intended to run and if it should be migrated.
- What if you find references
- If a schedule will re-create the job, you’ll need to remove or migrate that schedule first (and ensure the job won’t be enqueued after deletion).
4) Database migrations / columns (unlikely, but verify)
- What to check
- Any migrations or schema that mention LegacyDigestWorker (very unlikely, but possible if the design stored references to workers).
- How to verify
- Search migrations: rg -n "LegacyDigestWorker" db/migrate -S
- What if you find references
- Review the intent; typically there won’t be a dependency on a worker class in the DB, but if found, adjust migrations or remove the dependency.
5) Public API surface / external usage
- What to check
- Any public API, webhook, or external service that enqueues this worker by name or expects a digest to be sent on a schedule.
- Any documentation, README, or API clients that reference the LegacyDigestWorker.
- How to verify
- Search documentation and external-facing code for mentions of “legacy_digest” or “LegacyDigestWorker”.
- If the app exposes a REST/GraphQL endpoint that triggers digests, verify whether it routes through a worker or a direct mailer call.
- What if you find references
- Decide whether to migrate those calls or update external clients to use a different worker or approach.
6) Templates / configuration reachability
- What to check
- Any templating or config that relies on the presence of a named job (e.g., templates showing digest links, or configuration that implies a digest is sent).
- How to verify
- Scan templates for mentions of digest types or the worker class name.
- Confirm there are no template-driven enqueues of this worker.
- What if you find references
- If templates or config depend on this worker to exist, plan an alternate behavior or feature toggle before deletion.
7) Tests and test fixtures
- What to check
- Specs that reference LegacyDigestWorker or its behavior (e.g., tests that expect a digest email to be enqueued or delivered via the worker).
- How to verify
- Run test suite or search tests for "LegacyDigestWorker" or mailer digests in tests.
- What if you find references
- Update tests or ensure they are updated to reflect removal of this worker.
8) Observability and maintenance hooks
- What to check
- Any logging, metrics, or dashboards that track digest sending via this worker.
- How to verify
- Review logging statements or metrics that mention LegacyDigestWorker or digest_type.
- What if you find references
- Decide whether to migrate logs/metrics to a new target if you replace the worker.
Notes on the given facts
- The only caller information provided says: nothing in app/ calls LegacyDigestWorker.perform_async directly.
- This reduces risk of static code references, but dynamic/job-serialized references still matter.
- The scheduler config had a legacy_digest entry that was commented out three months ago.
- If that schedule is still loaded anywhere, it could re-enqueue the worker in the future; verify by inspecting scheduler config files and any runtime loading of schedules (e.g., sidekiq.yml, sidekiq-scheduler initializer).
- Sidekiq’s retry set currently holds ~400 jobs.
- This is a key red flag: some of those jobs may be for LegacyDigestWorker. If any exist, deleting the worker would cause those jobs to fail when retried or require a migration of those jobs before deletion.
Plain verdict
- Cannot determine safely from what was provided.
- There is a real risk that there are enqueued/retry/scheduled jobs referencing LegacyDigestWorker (especially given the non-trivial retry set and a previously configured scheduler entry). Without verifying the contents of the Sidekiq queues and scheduled tasks, deleting the worker could cause deserialization errors or orphaned jobs.
Recommended next steps (before deleting)
- Inspect repo for references to perform_async and the class name (as described above).
- Inspect Sidekiq queues, retry, scheduled, and dead sets for any jobs with klass == "LegacyDigestWorker".
- Confirm the status of any sidekiq-scheduler or sidekiq.yml entries related to legacy_digest; remove or migrate if necessary.
- If there are any dependent jobs or references, address them ( migrate to a new worker, remove enqueue points, or purge the jobs) before deletion.
- Only after confirming no references exist (or after migrating them) should you delete the worker.
Final answer: Cannot determine.
Editorial review (independent AI agents)
- Accuracy — pass (editorial-accuracy/google/gemini-2.5-flash)
- Safety — pass (editorial-safety/anthropic/claude-haiku-4.5)
- Usefulness — pass (editorial-usefulness/openai/gpt-5-nano)
