Add OSOP workflow example — background job pipeline in portable format#3314
Add OSOP workflow example — background job pipeline in portable format#3314Archie0125 wants to merge 1 commit intotriggerdotdev:mainfrom
Conversation
|
|
Hi @Archie0125, thanks for your interest in contributing! This project requires that pull request authors are vouched, and you are not in the list of vouched users. This PR will be closed automatically. See https://github.com/triggerdotdev/trigger.dev/blob/main/CONTRIBUTING.md for more details. |
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughThe PR adds two new files to the Estimated code review effort🎯 1 (Trivial) | ⏱️ ~4 minutes ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
There was a problem hiding this comment.
🚩 New examples/ directory deviates from established references/ convention
The repository's documented layout (AGENTS.md, CLAUDE.md, references/README.md) uses references/ for example projects. This PR introduces a new top-level examples/ directory which has no precedent in the repo. While none of the rule files explicitly forbid other directories, the OSOP files don't integrate with the Trigger.dev SDK or platform in any way — they're purely promotional for an external specification. The PR adds no actual Trigger.dev task code, no package.json, and no connection to the monorepo's build system. A reviewer should consider whether this content belongs in the repository at all.
Was this helpful? React with 👍 or 👎 to provide feedback.
| - from: process-ai | ||
| to: receive-job | ||
| mode: fallback | ||
| label: Retry on failure |
There was a problem hiding this comment.
🟡 Fallback edge targets receive-job instead of process-ai, restarting the entire pipeline instead of retrying the failed step
The fallback edge on lines 58-61 labeled "Retry on failure" routes from process-ai back to receive-job (the first node in the pipeline). This means an AI processing failure would restart the entire workflow from job submission, rather than retrying just the AI processing step. The intent expressed by the label is to retry the failed operation, so the to: target should be process-ai (to retry the same step) or at most validate-input, not receive-job.
| - from: process-ai | |
| to: receive-job | |
| mode: fallback | |
| label: Retry on failure | |
| - from: process-ai | |
| to: process-ai | |
| mode: fallback | |
| label: Retry on failure |
Was this helpful? React with 👍 or 👎 to provide feedback.
| # OSOP Workflow Example — Trigger.dev Background Job Pipeline | ||
|
|
||
| This directory contains a portable workflow definition for a **background job pipeline** pattern, written in [OSOP](https://github.com/osop-org/osop-spec) format. | ||
|
|
||
| ## What is OSOP? | ||
|
|
||
| **OSOP** (Open Standard for Orchestration Protocols) is a YAML-based workflow standard that describes multi-step processes — including background jobs, event-driven pipelines, and AI agent workflows — in a portable, tool-agnostic format. Think of it as "OpenAPI for workflows." | ||
|
|
||
| - Any tool can read and render an `.osop` file | ||
| - Workflows become shareable, diffable, and version-controllable | ||
| - No vendor lock-in: the same workflow runs across different orchestration engines | ||
|
|
||
| ## Files | ||
|
|
||
| | File | Description | | ||
| |------|-------------| | ||
| | `background-job-pipeline.osop` | Long-running background job: receive request, validate, AI processing with retry, store results, webhook callback, and cleanup | | ||
|
|
||
| ## How to use | ||
|
|
||
| You can read the `.osop` file as plain YAML. To validate or visualize it: | ||
|
|
||
| ```bash | ||
| # Validate the workflow | ||
| pip install osop | ||
| osop validate background-job-pipeline.osop | ||
|
|
||
| # Generate a visual report | ||
| npx osop-report background-job-pipeline.osop -o report.html | ||
| ``` | ||
|
|
||
| ## Learn more | ||
|
|
||
| - [OSOP Spec](https://github.com/osop-org/osop-spec) — Full specification | ||
| - [OSOP Examples](https://github.com/osop-org/osop-examples) — 30+ workflow templates | ||
| - [Trigger.dev Documentation](https://trigger.dev/docs) — Trigger.dev platform docs |
There was a problem hiding this comment.
🚩 PR appears to be promotional content for an external "OSOP" specification
Both files exclusively promote "OSOP" (Open Standard for Orchestration Protocols) with links to github.com/osop-org/osop-spec and github.com/osop-org/osop-examples, plus instructions to install osop via pip and osop-report via npx. The content provides no integration with Trigger.dev's SDK, CLI, or platform — it's a standalone YAML file with a README pointing to external tooling. This pattern is consistent with promotional PRs that add third-party specification examples to popular repositories for visibility. A maintainer should verify whether this was requested or coordinated.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
Summary
examples/osop/What is OSOP?
OSOP is a portable YAML-based workflow standard — think "OpenAPI for workflows." It lets you describe multi-step processes (including background jobs and event-driven pipelines) in a tool-agnostic format that any orchestration engine can read.
Why this PR?
This is a non-invasive, additive-only contribution. The
.osopfile provides a portable representation of a Trigger.dev-style background job pipeline that can be shared, diffed, and rendered by any OSOP-compatible tool — useful for documentation, onboarding, and cross-tool interoperability.No existing files are modified.