chore: queues launch post

[NathanFlurry]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[railway-app]

🚅 Deployed to the rivet-pr-4308 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
website	😴 Sleeping (View Logs)	Web	Feb 25, 2026 at 8:35 am
mcp-hub	✅ Success (View Logs)	Web	Feb 25, 2026 at 8:27 am
frontend-inspector	😴 Sleeping (View Logs)	Web	Feb 25, 2026 at 7:46 am
frontend-cloud	😴 Sleeping (View Logs)	Web	Feb 25, 2026 at 7:45 am
ladle	❌ Build Failed (View Logs)	Web	Feb 25, 2026 at 7:34 am

[NathanFlurry]

• chore(blog): add queues launch post image #4309
• chore: queues launch post #4308 👈 (View in Graphite)
• 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: Queues Launch Post

This PR adds the blog post announcing Queues for Rivet Actors, a multi-word title fix for code blocks, and a sitemap icon update.

Code Changes

website/src/components/v2/Code.tsx and website/src/mdx/rehype.ts — Multi-word title fix

The fix is correct and clearly motivated by the blog post's code block tabs ("Message Loop", "Tick Loop", "Multiple Queues", etc.). Both files now accumulate non-flag tokens into titleParts and join them with spaces.

One concern: the title parsing logic is duplicated across two files that must stay in sync. If one diverges (e.g., a new @flag is added), titles could render differently between the Astro MDX pipeline and the React Code component. A shared utility function or a shared regex/parser would prevent that drift.

website/src/mdx/rehype.ts — hProperties meta source

Adding hProperties.meta/metastring/metaString as fallback candidates is a good defensive fix. It mirrors the existing candidates but from the hast properties bag, which some remark/rehype plugins write to instead of node.data.

website/src/sitemap/mod.ts — Icon update

faMailbox is semantically better than faListUl for a Queues entry. Good change.

---

Blog Post: page.mdx

The content is clear, well-structured, and the code examples demonstrate the feature well. A few notes:

Minor issues in example code

1. gpt-5 model references — openai("gpt-5") appears in multiple examples. As of the post date this model doesn't exist publicly. Consider using a model that exists today (e.g. gpt-4o, gpt-4.1), or use a placeholder comment like // your model here. Using a non-existent model in published launch docs could confuse readers who try to run the examples.

2. result.text after abort (Cancellable Agent example) — In the cancellable agent, generateText is called with abortSignal: runSignal. If the stop queue fires and aborts mid-generation, generateText will throw. The .finally(() => { stopController.abort(); }) call handles cleanup, but the thrown error propagates up and will break the outer for await loop. Either wrap in a try/catch that skips the DB write on abort, or add a note explaining that the actor will restart and pick up the next message. As written it could be confusing to readers.

3. Silent .catch(() => {}) on the stop-queue race — Both the "Multiple Queues" and "Cancellable Agent" examples use this pattern:

   c.queue.next({ names: ["stop"], signal: runSignal })
     .then(([stopMessage]) => { if (stopMessage) stopController.abort(); })
     .catch(() => {});

   This is correct for the abort-signal case, but the empty catch also silently swallows unexpected errors. A brief inline comment explaining that the only expected error is an AbortError would help readers understand the intent instead of thinking this is a bad practice.

Frontmatter

All required fields (title, description, author, published, category) are present. ✓

---

Summary

The code fixes are correct and necessary for the blog post to render properly. The blog post itself reads well. The main actionable items before merging:

• Replace gpt-5 with an existing model (or a comment placeholder)
• Address the unhandled abort throw in the Cancellable Agent example (try/catch or explanatory comment)
• Add a short comment next to the empty .catch(() => {}) calls explaining the intent

The duplicated title-parsing logic is worth a follow-up but not a blocker for this PR.