Recipes
Goal-oriented patterns for the operations plugin authors do most often. Each recipe is short — a goal, a code block, a few notes, and links to related material. If the recipe doesn't fit, the Tutorials cover end-to-end builds and the API Reference covers exact symbol surfaces.
Reading experiments
| Recipe | When |
|---|---|
| Reading experiments | Look up one experiment, paginate, filter by status / project |
| Querying plugin data | SQLAlchemy patterns on plugin-owned tables |
Writing results
| Recipe | When |
|---|---|
| Writing results | Save / append PluginAnalysisResult, preserve run history, reference produced artifacts by ID |
Permissions and identity
| Recipe | When |
|---|---|
| Route permissions | require_plugin_role, combining with platform permissions |
Reliability
| Recipe | When |
|---|---|
| Error handling | Map PluginException subclasses to HTTP responses; user-facing vs developer-facing |
| Logging & tracing | Structured logs via get_plugin_logger; request-scoped fields |
| Testing plugins | In-memory repos, fixtures, end-to-end tests with TestClient |
Schema evolution
| Recipe | When |
|---|---|
| Backfill migrations | Schema changes plus chunked data backfill, idempotent on retry |
Domain-specific
| Recipe | When |
|---|---|
| R integration | Calling R from a Python plugin via rpy2 or subprocess |
Pattern
Every recipe page follows the same shape: Goal → Code → Notes → Related. Read the goal and the code first; the notes are the gotchas you'll hit when adapting the pattern.