AlCalzone

I don't understand the use case for that trigger. Why would an adapter care for this? IMO the interesting part is when the setState is done.

You can already do that: for (...) { await setStateAsync(...); } // stuff to do after initalizing

I think I need some pseudo code using the proposed method to understand what you mean. For me it seems that two for loops like above should be enough for...

I recently found something very interesting: https://github.com/sindresorhus/p-queue That module is basically a Promise task queue. Every call to the DB could just add a task to that queue and it...

We have callback-style APIs and need to wrap them in Promises (which we already do in many cases) to be able to use that.

Do we track dependencies in the repo files? If not that might be worth it to build the dependency graph.

At which point is the dependency relevant? `iob add`? Because otherwise, dev-server and testing would need to handle this aswell.

IMO, this is what scripts are for. Adding it here would duplicate functionality and increase complexity. Especially since the synchronous getState only exists in the script adapter.

Any reason you can't put the ID into the filename too?

See my initial comment :) > "blocked" isn't self explanatory IMO. I'm fine with blocklisted