Send Event

Inngest

Users should be able to reply a single function run or a group of function runs based on a time + status filter query. Both should be achievable via the Inngest dashboard.

Function replay

Defining event types is a pretty rough experience right now, with many users creating their own methods for defining the required event structure. I've avoided pushing smaller changes to this such as generic type shortcuts as we know it needs an overhaul.

Schemas - Better SDK Typing

Ruby SDK

Add a tool which allows for continual linear subscriptions to an event stream, eg: `step.subscribe("event/name", { if: "xyz == 123", timeout: "10m" }, (acc, async, ctx) => {})`.  This lets us listen for all events of a type within a function.

Flink-style stream reducing: `step.subscribe`

We should have a public API, allowing us to do things like:  cancelling jobs by run ID;  looking up all jobs from an event ID;  fetching a single job's status.

Public API

Allow full text searching of function output or event data (not including user data, as that's encrypted).  This allows you to find eg. an event containing a specific ID.

Full text event & function output search

How the SDK interacts with the executor to run step functions is shrouded in mystery. Open this up by providing "How it works" docs.

Docs: Q2 '23 refactor

Steps should be able to override retry policies and set their own concurrency keys

Per-step options

Users should be able to try/catch steps that permanently fail, alongside having the function's onFailure error handler run.  This lets you write regular idiomatic error handling code.

Per-step failure handling

Allow function logs to be filtered by date and by status.

Function Logs Filtering

Inngest users may have multiple accounts for personal work, their company and/or clients. Users desire to have a single shared login across multiple Inngest, isolated accounts each with separate billing.

Multiple Inngest Accounts for Users

This would enable devs to add something like Sentry or BugSnag to Inngest's `serve` handler and capture stack traces.

Add support for error monitoring libraries in SDK

Allow passing in regions, eg: `eu`, within HTTP headers when sending events, ensuring that all data is parsed, stored, and executed within the specified region.

Multi-region data support

Improve the SDK logging so that we guarantee delivery, log on step errors, and (try to) ensure that log entries aren't double logged.

Better SDK logging

Add the ability to provide generic middleware to individual SDK functions or all SDK functions via the client similar to Express. This enables a firm foundation for many other features, such as logging, data transformers, shared context, and more.

Generic SDK Middleware

We should allow functions to consume "batches" of events, specifying a maximum batch size or maximum timeout waiting for the full batch.  This allows people to process high volumes of events with fewer invocation costs.

Event batching

Many errors within the SDK are handled in code, but not logged for users to see, meaning it can be unclear for users how failures should be remedied. We can fix this by providing a number of more in-depth, user-facing errors across the SDK.

Actionable SDK Errors

Expose greater dials over concurrency, including:  custom function concurrency queues (eg. per user), per-step concurrency queues (eg. for APIs used in many functions)

Custom concurrency queues

We should add a library and SDK utilities for mocking SDK steps for each function.

Mock testing library

Integrate and fully support otel trace IDs within events, functions, log drains, and metadata sent to functions.

Tracing support

Implement a durable API layer using SQL within the open-source server to allow E2E self-hosting.

Self hosting

Build an SDK that allows defining Inngest functions using Python.

Go SDK

Python SDK

Tools like superjson are common in the JS ecosystem, allowing users to maintain objects such as dates across network boundaries. The SDK can support these patterns by allowing a "transformer" to serialize/deserialize data passing to/from Inngest.