Skip to content

feat: update documentation structure for trigger actions and queues#1327

Merged
sergiofilhowz merged 2 commits intomainfrom
feat/queue-documentation
Mar 18, 2026
Merged

feat: update documentation structure for trigger actions and queues#1327
sergiofilhowz merged 2 commits intomainfrom
feat/queue-documentation

Conversation

@sergiofilhowz
Copy link
Contributor

@sergiofilhowz sergiofilhowz commented Mar 18, 2026

  • 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.

https://motiadev-feat-queue-documentation.mintlify.app/

Summary by CodeRabbit

  • Documentation
    • Added comprehensive Trigger Actions guide with mode comparisons, decision flow, and multi-language examples (Node/TS, Python, Rust).
    • Expanded queue how-to and module docs to emphasize Named Queues, enqueue semantics, FIFO behavior, ordering guarantees, retry/DLQ flows, and adapter guidance with diagrams.
    • Restructured site navigation to a versioned layout.
    • Removed the prior architecture overview for the queue system.

- 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.
@vercel
Copy link
Contributor

vercel bot commented Mar 18, 2026

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

Project Deployment Actions Updated (UTC)
iii-website Ready Ready Preview, Comment Mar 18, 2026 2:11pm
motia-docs Ready Ready Preview, Comment Mar 18, 2026 2:11pm

Request Review

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Mar 18, 2026

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 96f7b844-0a50-47db-82c3-92a387f19c06

📥 Commits

Reviewing files that changed from the base of the PR and between 7f4e2de and 13e902d.

📒 Files selected for processing (1)
  • docs/modules/module-queue.mdx

📝 Walkthrough

Walkthrough

Deleted 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

Cohort / File(s) Summary
Navigation / Manifest
docs/docs.json
Replaced flat tabs with versions[] containing tabs (Documentation, API Reference); reorganized groups/pages and added version/tag metadata.
Removed Architecture Doc
docs/architecture/queue-system.mdx
Deleted entire architecture file describing Named Queues rationale, engine consumer loop, TriggerAction semantics, RabbitMQ topology, and adapter comparisons.
Trigger Actions Guide
docs/how-to/trigger-actions.mdx
New comprehensive how-to (multi-language examples, action matrix, diagrams, decision flow) describing Synchronous, Void, and Enqueue modes for trigger().
Queue How-to Rework
docs/how-to/use-queues.mdx
Extensive rewrite: centralized iii-config.yaml examples, TriggerAction.Enqueue usage, FIFO semantics/message_group_field rules, retry/DLQ flows, adapter behavior, and multi-language code samples.
Queue Module Updates
docs/modules/module-queue.mdx
Small edits: added Trigger Actions block, clarified FIFO/concurrency behavior, updated adapter descriptions and adapter comparison rows.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

Suggested reviewers

  • ytallo

Poem

🐰 I hopped through docs both old and new,

Named queues neatly lined in view,
Triggers sing in sync or enqueue,
Configs crisp, diagrams in tow —
A joyful hop, a docs-review! 🥕📚

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the main change: updating documentation structure for trigger actions and queues. It is concise, clear, and directly reflects the changeset's primary focus.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feat/queue-documentation
📝 Coding Plan
  • Generate coding plan for human review comments

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Tip

Migrating from UI to YAML configuration.

Use the @coderabbitai configuration command in a PR comment to get a dump of all your UI settings in YAML format. You can then edit this YAML file and upload it to the root of your repository to configure CodeRabbit programmatically.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 5

🧹 Nitpick comments (2)
docs/how-to/trigger-actions.mdx (1)

389-393: Prefer RegisterFunctionMessage::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 None fields 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: Prefer RegisterFunctionMessage::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

📥 Commits

Reviewing files that changed from the base of the PR and between 115674a and 7f4e2de.

📒 Files selected for processing (5)
  • docs/architecture/queue-system.mdx
  • docs/docs.json
  • docs/how-to/trigger-actions.mdx
  • docs/how-to/use-queues.mdx
  • docs/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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants