feat: update documentation structure for trigger actions and queues#1327
feat: update documentation structure for trigger actions and queues#1327sergiofilhowz merged 2 commits intomainfrom
Conversation
- Introduced a new document on trigger actions detailing synchronous, fire-and-forget, and enqueue modes. - Enhanced the use-queues documentation with clearer steps and examples for defining and using named queues. - Removed the outdated queue-system document to streamline content. - Updated the module-queue documentation to reflect changes in queue configuration and usage.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughDeleted legacy architecture doc and reorganized documentation: introduced versioned navigation, added a comprehensive Trigger Actions how-to, and rewrote queue how-to and module docs to center Named Queues, TriggerAction semantics, FIFO behavior, adapter differences, and detailed configuration examples. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 Tip Migrating from UI to YAML configuration.Use the |
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (2)
docs/how-to/trigger-actions.mdx (1)
389-393: PreferRegisterFunctionMessage::new("...")in these Rust snippets.These examples only need the id, so the shorter constructor is the repo’s documented pattern and avoids repeating the optional
Nonefields everywhere.Based on learnings, “when documenting RegisterFunctionMessage and only the id is needed, instantiate via RegisterFunctionMessage::new("id").”
Also applies to: 550-554, 711-715, 891-895
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/how-to/trigger-actions.mdx` around lines 389 - 393, Replace verbose RegisterFunctionMessage struct literals that set only id and leave other fields as None (e.g., RegisterFunctionMessage { id: "orders::create".into(), description: None, request_format: None, response_format: None, metadata: None, invocation: None }) with the concise constructor RegisterFunctionMessage::new("orders::create"); update all similar occurrences (the ones called out and any other snippets that only provide id) so they use RegisterFunctionMessage::new("...") instead of listing None fields; keep the id string the same when migrating each instance.docs/how-to/use-queues.mdx (1)
529-533: PreferRegisterFunctionMessage::new("...")in the Rust examples.These snippets only set the id, so the shorter constructor is the documented pattern and keeps the examples easier to scan.
Based on learnings, “when documenting RegisterFunctionMessage and only the id is needed, instantiate via RegisterFunctionMessage::new("id").”
Also applies to: 715-719, 880-884
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/how-to/use-queues.mdx` around lines 529 - 533, Replace the verbose struct literal instantiation of RegisterFunctionMessage with the concise constructor when only the id is set; e.g., change the block creating RegisterFunctionMessage { id: "orders::create".into(), description: None, request_format: None, response_format: None, metadata: None, invocation: None } to RegisterFunctionMessage::new("orders::create") and make the same replacement for the other similar snippets using RegisterFunctionMessage.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/how-to/trigger-actions.mdx`:
- Line 8: The wording is misleading: update the text around trigger() to
distinguish "invocation modes" from TriggerAction enum values—explain that there
are three invocation modes (synchronous/default when action is omitted, and two
enum-backed actions: Void and Enqueue), change the heading "The Three Trigger
Actions" to "The Three Invocation Modes", and clarify that only Void and Enqueue
are members of the TriggerAction enum while synchronous is the default behavior
when no action is provided to trigger().
In `@docs/how-to/use-queues.mdx`:
- Around line 748-759: The documentation incorrectly claims that a FIFO queue
with the shown queue_configs (ledger, type: fifo, message_group_field:
account_id) will process "different accounts in parallel" while the
implementation uses prefetch=1 and therefore serializes processing globally;
update the prose to state that a FIFO queue with prefetch=1 is globally
serialized and does not provide per-group concurrency, and describe the two
correct options to achieve parallelism: implement per-message-group concurrency
in the worker or shard work across multiple FIFO queues (and remove or rephrase
the misleading "Different accounts can process in parallel" sentence); keep
references to queue_configs/ledger/message_group_field/prefetch=1 so readers can
find the relevant example.
- Around line 224-238: The docs show one too many backoff delays for the
configured attempt budget: clarify that backoff delays occur between delivery
attempts so the number of delays equals max_retries - 1, and then either remove
the final row from the table (so the "Configure retries and backoff" Step and
its table only lists 4 delays for max_retries: 5) or change the sample config to
max_retries: 6 if you want five delays to remain; update the explanatory
sentence around `max_retries` and `backoff_ms` to state “delays = max_retries -
1” and apply the same correction to the other occurrences mentioned (the other
blocks referenced).
In `@docs/modules/module-queue.mdx`:
- Around line 113-115: The documentation references to
"../architecture/queue-system#why-fifo-uses-prefetch1" (inside the Warning
titled "FIFO and concurrency" in module-queue.mdx) will 404 because
docs/architecture/queue-system.mdx was removed; update the link to point to an
existing page that explains why FIFO uses prefetch=1 (or copy the brief
rationale inline into the Warning text), and apply the same fix to the other
occurrence noted at the later reference (line range 160-160). Ensure the updated
link text still reads "[Why FIFO uses prefetch=1]" or keep the explanation
inline for self-containment.
- Around line 184-188: The sentence starting "Regardless of adapter, retry
semantics, concurrency enforcement, and FIFO ordering behave identically…" is
too broad; change it to qualify that these behaviors are identical only for
adapters that support named-queue consumption (i.e., adapters that let the
engine own the consumer loop for named queues). Update the rationale link target
from "../architecture/queue-system#why-the-engine-owns-the-consumer-loop" to the
correct current architecture page/anchor that explains why the engine owns the
consumer loop (replace the removed queue-system link with the architecture page
that contains the same explanation). Also ensure the nearby "Choosing an
adapter" reference still points to "../how-to/use-queues#choosing-an-adapter".
---
Nitpick comments:
In `@docs/how-to/trigger-actions.mdx`:
- Around line 389-393: Replace verbose RegisterFunctionMessage struct literals
that set only id and leave other fields as None (e.g., RegisterFunctionMessage {
id: "orders::create".into(), description: None, request_format: None,
response_format: None, metadata: None, invocation: None }) with the concise
constructor RegisterFunctionMessage::new("orders::create"); update all similar
occurrences (the ones called out and any other snippets that only provide id) so
they use RegisterFunctionMessage::new("...") instead of listing None fields;
keep the id string the same when migrating each instance.
In `@docs/how-to/use-queues.mdx`:
- Around line 529-533: Replace the verbose struct literal instantiation of
RegisterFunctionMessage with the concise constructor when only the id is set;
e.g., change the block creating RegisterFunctionMessage { id:
"orders::create".into(), description: None, request_format: None,
response_format: None, metadata: None, invocation: None } to
RegisterFunctionMessage::new("orders::create") and make the same replacement for
the other similar snippets using RegisterFunctionMessage.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 8d5a96b3-a2e6-4d97-8266-3d1ca4e14a3b
📒 Files selected for processing (5)
docs/architecture/queue-system.mdxdocs/docs.jsondocs/how-to/trigger-actions.mdxdocs/how-to/use-queues.mdxdocs/modules/module-queue.mdx
💤 Files with no reviewable changes (1)
- docs/architecture/queue-system.mdx
- Removed unnecessary references to external links in the FIFO and RabbitMQ sections for clarity. - Streamlined explanations regarding queue behavior and retry semantics to enhance readability.
https://motiadev-feat-queue-documentation.mintlify.app/
Summary by CodeRabbit