Oban
PassAudited by ClawScan on May 1, 2026.
Overview
This instruction-only Oban helper is aligned with building Elixir background jobs, but generated workers should be reviewed because they may run on schedules, call webhooks, or change application data.
This appears safe to use as an Oban design/reference skill. Before merging generated code, review any scheduled jobs, webhook delivery workers, cleanup tasks, and import workers for proper validation, scoping, testing, and production safeguards.
Findings (3)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Scheduled workers can keep performing cleanup, metrics, email, or reporting tasks without a person triggering each run.
The skill explicitly teaches recurring scheduled workers. This is disclosed and central to Oban, but it creates application work that continues running after deployment.
{Oban.Plugins.Cron, crontab: [{"0 2 * * *", MyApp.Workers.DailyCleanup}, {"*/5 * * * *", MyApp.Workers.MetricsCollector}]}Review cron schedules, queues, environment-specific configuration, logging, and monitoring before enabling generated recurring jobs.
If generated webhook code accepts untrusted URLs or overly sensitive payloads, the application could send data to unintended endpoints.
The webhook worker example posts payloads to a URL supplied in job arguments. That is expected for webhook delivery, but destination and payload validation matter if adapted into a real app.
%{"url" => url, "event" => event, "payload" => payload} = args ... Req.post(url, json: payload, headers: headers, receive_timeout: 25_000)Validate subscriber URLs, block internal/private network destinations where appropriate, sign payloads carefully, and avoid placing unnecessary secrets or sensitive data in job arguments.
A copied cleanup or import worker with the wrong filters could delete, overwrite, or repeatedly change application data.
The reference examples include bulk deletion and replacement-style database writes. These are normal background-job patterns, but mistakes can affect many records.
from(t in MyApp.Accounts.UserToken, where: t.inserted_at < ^cutoff) |> Repo.delete_all() ... MyApp.Repo.insert_all(MyApp.Items.Item, entries, on_conflict: :replace_all)
Add tests, retention safeguards, tenant scoping, transactions where appropriate, dry-run/logging options for destructive jobs, and manual review before production deployment.