What are the phases of Ktor's ApplicationCallPipeline, and what determines the order interceptors run in?

## The pipeline model Ktor does not process a request with a fixed chain of hard-coded steps. It builds an `ApplicationCall` and pushes it through a **pipeline**: an ordered collection of named phases, where each phase holds zero or more interceptors. Plugins do their work by registering interceptors in the phase appropriate to their job. `ApplicationCallPipeline` declares these phases, in execution order: - **Setup** — preparing the call before anything inspects it. - **Monitoring** — observation: logging, tracing, metrics. It runs early precisely so that an interceptor here wraps everything that follows and can measure it. - **Plugins** — where most plugin behaviour lives. - **Call** — routing and your route handler. - **Fallback** — reached when nothing has responded. This is why an unmatched path produces a 404 without you writing one. (The `Plugins` phase was called `Features` before Ktor 2.0, when the whole extension concept was renamed. Old blog posts and answers still use the old name.) ## Interception is nested, not linear An interceptor is a suspending lambda that receives the call. Crucially it can run code, then hand control onward, then run more code when control returns: ``` intercept(ApplicationCallPipeline.Monitoring) { val start = System.nanoTime() proceed() // run the rest of the pipeline val micros = (System.nanoTime() - start) / 1000 call.application.log.info("{} took {}us", call.request.uri, micros) } ``` `proceed()` executes the remainder of the pipeline and suspends until it finishes. That gives you the familiar around-advice shape. If an interceptor **does not** call `proceed()`, execution continues after the block returns — unless the interceptor calls `finish()`, which stops the pipeline immediately. Short-circuiting like that is exactly how a plugin can reject a call — responding and finishing — without the route handler ever running. Because the shape is nested, an interceptor in an *earlier* phase wraps everything in later phases. That is why observation belongs in `Monitoring`: it sees the whole call, including work done by plugins in `Plugins` and the handler in `Call`. ## What decides order Two things, in this priority: 1. **The phase.** Fixed and total. Anything in `Monitoring` runs before anything in `Plugins`, which runs before `Call`. No amount of install ordering changes that. 2. **Registration order within the phase.** Interceptors added to the same phase run in the order they were added. For plugins, that is the order of your `install()` calls in the module function. So when someone says "plugin order matters in Ktor," the accurate version is: it matters *among plugins that register in the same phase*. Two plugins in different phases are ordered by their phases regardless of how you wrote the installs. This has a very practical consequence for response-modifying plugins. If plugin A rewrites the response body and plugin B adds a header based on that body, their relative order changes the outcome — and you control it by install order when they share a phase. Compression and caching-header behaviour are the usual real-world examples: the observable result depends on which one sees the response first. ## Custom phases A pipeline can also be extended. You can define your own `PipelinePhase` and insert it relative to an existing one — before or after a named phase — then register interceptors there. This is the escape hatch when "same phase, controlled install order" is too blunt: it lets a plugin guarantee it runs after a specific phase without depending on the order in which someone happened to write the install calls. Plugins that need deterministic placement do exactly this internally. ## Routing is a pipeline too The `Call` phase is where routing runs, and routing has its own nested pipelines per route. That is how route-scoped plugins can exist at all: their interceptors are attached to a route's pipeline rather than the application's, so only calls matching that route pass through them. ## How to answer well Name the five phases in order, state the two-level ordering rule (phase first, then registration order within a phase), and demonstrate that you know `proceed()` makes interception nested rather than a one-shot filter. Add the placement heuristic — observation in `Monitoring` so it wraps everything, request/response manipulation in `Plugins`, handling in `Call` — and mention custom phases as the tool for deterministic ordering when install order is too fragile to rely on.