chore(gas): add support for find_workflows

[NathanFlurry]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
rivetkit-serverless	Error		Jan 2, 2026 11:34pm

3 Skipped Deployments

Project	Deployment	Review	Updated (UTC)
rivet-cloud	Ignored		Jan 2, 2026 11:34pm
rivet-inspector	Ignored	Preview	Jan 2, 2026 11:34pm
rivet-site	Ignored	Preview	Jan 2, 2026 11:34pm

[NathanFlurry]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• feat(dash): surface actor errors in ui #3743
• fix(dash): use ineligible icon for runners #3742
• feat(dash): show runner pool errors #3741
• chore: update engine-full sdk #3740
• feat(engine): return error for pending actors #3730
• chore(gas): add support for find_workflows #3739 👈 (View in Graphite)
• chore(docs): document abort signal #3673
• chore(rivetkit): clean up logging configuration #3672
• chore(rivetkit): RIVET_EXPOSE_ERRORS #3671
• chore(rivetkit): specialize context types for better compiler errors #3669
• fix(rivetkit): fix c.client not respecting correct origin #3668
• fix(rivetkit): allow providing no args to createRivetKit #3667
• main

---

How to use the Graphite Merge Queue

Add the label merge-queue to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[claude]

PR Review: Add support for find_workflows batch operation

Summary

This PR adds a batch version of find_workflow that allows finding multiple workflows in a single database transaction. The implementation is generally solid and follows existing patterns in the codebase.

---

Code Quality & Best Practices

✅ Strengths:

• Consistent API design across all context types (ActivityCtx, OperationCtx, StandaloneCtx, TestCtx)
• Proper use of tracing instrumentation
• Follows existing patterns in the codebase
• Good separation of concerns with the common module
• Appropriate use of try_join_all for concurrent execution within the transaction

⚠️ Areas for Improvement:

1. Documentation clarity - The doc comments say "in a single batch transaction" but the implementation details could be clearer about what this means:

   • engine/packages/gasoline/src/ctx/activity.rs:90
   • The batch queries are executed concurrently within a single transaction, not sequentially
   • Consider clarifying that this provides atomicity/consistency guarantees

2. Error handling granularity - engine/packages/gasoline/src/db/kv/mod.rs:1028

   • If any single query in the batch fails, the entire batch fails
   • This is probably the desired behavior, but worth documenting explicitly
   • Consider whether partial results might be useful in some scenarios

---

Potential Issues

1. Performance consideration - engine/packages/gasoline/src/db/kv/mod.rs:1021-1024

   • Each find_workflow_inner call streams results and may iterate through many workflows
   • With large batches, this could hold the transaction open for a long time
   • Consider adding a comment about recommended batch sizes or documenting limitations

2. Metrics granularity loss - engine/packages/gasoline/src/db/kv/mod.rs:1032

   • Using "batch" as the workflow_name loses visibility into which workflows are being queried
   • This makes it harder to debug performance issues
   • Consider alternatives like recording per-query metrics or adding batch_size dimension

---

Security Concerns

No security issues identified. The implementation properly:

• Reuses existing validation in find_workflow_inner
• Uses the same transaction isolation as single queries
• Doesn't introduce any new attack surfaces

---

Performance Considerations

1. Transaction duration - The batch operation holds a database transaction open while executing multiple concurrent queries. For large batches or slow queries, this could block other transactions and increase database contention. Recommend documenting batch size limits.

2. Memory usage - All results are collected into a Vec before returning. For very large batches, consider whether streaming results would be beneficial.

3. Positive note: Using try_join_all for concurrent execution within the transaction is good for performance.

---

Test Coverage

❌ Missing test coverage:

• No new tests added for the find_workflows batch functionality
• Should add tests covering:
  • Basic batch query functionality
  • Empty batch (edge case)
  • Single-item batch
  • Multiple queries with different workflow names
  • Multiple queries with same workflow name but different tags
  • Batch with some queries returning None
  • Error cases (e.g., invalid tags)

Recommendation: Add integration tests to verify batch behavior.

---

Summary & Recommendations

Priority Issues:

1. 🔴 High: Add test coverage for the new batch functionality
2. 🟡 Medium: Improve metrics granularity to avoid losing observability
3. 🟡 Medium: Document performance characteristics and recommended batch sizes

Nice to have:

• Add example usage in doc comments
• Consider logging individual workflow names at debug level for troubleshooting

Overall, this is a well-implemented feature that follows existing patterns. With test coverage and improved observability, it will be production-ready.

---

Review generated with attention to CLAUDE.md conventions and Rust best practices.