theoai-inngest_skill

This skill helps you develop, optimize, and troubleshoot Inngest workflows with best practices for events, steps, error handling, and observability.

0

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill get-theo-ai/agent-skills --skill theoai-inngest

  • SKILL.md4.3 KB

Overview

This skill provides practical guidelines and best practices for building and maintaining Inngest workflows and functions. It focuses on correct step usage, serialization limits, event schemas, error handling, and performance patterns to help you write durable, observable, and efficient event-driven code. Use it to avoid common pitfalls and to design maintainable serverless stateful jobs.

How this skill works

The skill inspects Inngest function structure, step usage, event typing, and common anti-patterns, then recommends concrete changes: where to place non-deterministic code, how to serialize returns, and which step primitives to prefer. It highlights patterns for parallelism, fanout, and tracing while flagging issues like nested steps, oversized payloads, and missing Zod event schemas. It also advises on logging, retries, and when to use NonRetriableError.

When to use it

  • Creating new Inngest functions or refactoring existing ones
  • Designing or editing event schemas and return types
  • Optimizing workflow performance, concurrency, or cost
  • Troubleshooting orchestration, retries, or observability issues
  • Writing long-running or AI-driven background jobs that must survive failures

Best practices

  • Place non-deterministic operations (DB/API/randomness) inside step.run() to preserve determinism and correct retries
  • Avoid nesting or passing step objects; treat each step as an independent HTTP-executed unit
  • Keep serialized returns under 4MB and avoid returning complex functions or unserializable objects
  • Prefer step.run() for visual traceability; use step.invoke() only when separate concurrency control is required
  • Use Inngest step primitives (fetch, waitForEvent, delay, sleepUntil) instead of blocking loops; leverage Promise.all for parallel steps
  • Type events and returns with Zod and use Inngest's logger instead of console.log

Example use cases

  • A long-running invoice processing workflow split into durable steps with retries and observability
  • An AI inference pipeline where each model call is a step.run() to ensure correct retries and metrics
  • Fanout email dispatch: aggregate parallel send steps with Promise.all and use step.run() to keep traces grouped
  • Webhook-driven order handling that types event payloads with Zod and returns compact serialized results
  • A scheduled cleanup job that uses step.sleepUntil or step.delay instead of busy-wait loops

FAQ

Each step executes as a separate HTTP request and may be retried; placing non-deterministic calls inside step.run() ensures the step’s inputs and behavior are captured and retried deterministically by Inngest.

When should I use step.invoke() instead of step.run()?

Use step.invoke() when you need independent concurrency limits or separate operational control for a subtask; prefer step.run() for better aggregation and visualization under the parent function.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational