Execution · Lesson 03 of 03
Interaction, concurrency, listeners, and cleanup
How Ota handles concurrent tasks, service listeners, and cleanup after execution — and what contract authors must declare to make this safe.
Learning objectives
- Declare a task with a service listener dependency
- Understand what cleanup must be declared vs inferred
- Explain concurrency limits and why Ota is conservative
Prerequisites
Concurrent executions are admitted by resource identity, not task name alone. Ota tracks listener ownership, write namespaces, environment materialization, execution mode, and lifecycle posture to distinguish safe coexistence from real conflicts.
Listeners and writable state are separate conflicts
Two service tasks may coexist when their effective listeners and writable namespaces are disjoint. A free host port can resolve a runtime_listener conflict, but it cannot resolve overlapping node_modules, generated state, or another shared write boundary.
ota run --container --host-port 3001 devCleanup is evidence-bearing work
Ephemeral resources require identified cleanup ownership and terminal confirmation. Ota can claim only removal of the exact boundary it created and observed. It must not infer host-wide process absence or provider cleanup from a task exit alone.
Canonical terminology
Evidence boundary for this lesson
Establishes
- The worked examples establish the lesson's canonical Ota distinctions for its stated scope.
Does not establish
- Reading the lesson does not validate a repository, execute its tasks, or establish organizational acceptance.
Knowledge check
Why might changing --host-port still leave an active execution conflict?
A new port can resolve only runtime_listener ownership. Shared writable state, environment materialization, or another typed resource conflict may still overlap.