Incorrect documentation for function concurrency

[antonio-bluco]

Hi,

This page has wrong documentation around function concurrency.

Verbatim:

This limits all accounts to a single execution for this function, based off of the event.data.account_id field.

Similarly in the parallel import example below, the following explanation is given:

Inngest ensures that the concurrency (1) applies to each unique value for event.data.customerId. This allows different customers to have functions running at the same exact time, but no given customer can have two functions running at once!

To my understanding, these statements are both wrong. What the concurrency parameter controls is parallel execution of steps, not of functions. So if your function consists of a single step, this works - but if you function has 3 steps, then both functions can run at the same time (just one step at a time).

This is problematic if you need the second invocation to wait for the first invocation to fully finish before starting (due to some db state which needs to be in a certain way, for example) - and IMO the docs are very confusing on this point.

Btw, is there a way to achieve function-level concurrency control, instead of steps-level?

[01programs]

Thank you! I've been pointing out the same thing.

Here my original problem statement from discord:

I'm trying to implement a concurrency limit at the function level rather than at the (executing) step level.

The function has two steps:
Step 1: Starts an async job that runs for an arbitrary amount of time.
Step 2: Waits for a "job-done" event.

I can only run x async jobs concurrently at any time but there's no active executing step on my end - hence no working concurrency limit.

The docs on concurrency, throttling, rate limiting, and debouncing didn't enlighten me.

Does anybody have an idea on how to implement this?

This seems like a core feature, no?