Skip to content

feat: name Server instances and attribute workers to them#2529

Merged
AlliBalliBaba merged 4 commits into
php:refactor/phpserverfrom
nicolas-grekas:server-name
Jul 20, 2026
Merged

feat: name Server instances and attribute workers to them#2529
AlliBalliBaba merged 4 commits into
php:refactor/phpserverfrom
nicolas-grekas:server-name

Conversation

@nicolas-grekas

@nicolas-grekas nicolas-grekas commented Jul 19, 2026

Copy link
Copy Markdown
Contributor

Follow-up to the discussion in #2499 (#2499 (comment)): this adds an optional human-readable name to Server, targeting the refactor/phpserver branch.

Three commits, each independently buildable:

  1. Core: NewServer() takes a name as first argument. When empty, it defaults to the server index at registration time. A Server.Name() getter is exposed; the field stays private.
  2. Caddy: a name is resolved for each php_server block when registering the module. Cascade: first host of the enclosing route's host matcher (e.g. api.example.com), else the first listener address of the http server containing the module. Reuses the *caddyhttp.App already fetched in Provision().
  3. Consumer: createUniqueWorkerName() qualifies colliding worker names with the server name before falling back to the numeric postfix. Two blocks each declaring a queue worker now yield queue and two.example.com:queue instead of queue and queue_1, so metrics stay attributable. Non-colliding names are unchanged (no BC impact on metric labels).

The last commit is separable if you'd rather keep the naming behavior untouched for now; the first two are what #2398 needs to reuse Server as the scope for background workers without a parallel label registry.

Not included on purpose: enforcing name uniqueness across servers (the index remains the identity), and any change to NewServer's signature style. If you'd prefer variadic ServerOptions over the growing positional list, I'm happy to adapt.

The name is a human-readable identifier passed to NewServer(); when
empty it defaults to the index the server gets at registration time.
It allows attributing workers, metrics and logs to a specific server.
The name is resolved when registering the module: first host of the
enclosing route's host matcher, else the first listener address of the
http server containing the module.
Two php_server blocks declaring a worker with the same name (or same
default file name) used to get an order-dependent numeric postfix
("queue", "queue_1"), making metrics attribution ambiguous. The
colliding name is now qualified with the resolved server name
("two.example.com:queue") before falling back to the postfix.
@AlliBalliBaba

Copy link
Copy Markdown
Contributor

If determining the server name like this is reliable then this looks fine to me 👍

Since a route can potentially contain multiple php_server blocks, it probably should also be possible to name a block directly.

php_server{
    name "my-server"
}

Signed-off-by: Alexander Stecher <45872305+AlliBalliBaba@users.noreply.github.com>
@AlliBalliBaba
AlliBalliBaba merged commit 7e2460d into php:refactor/phpserver Jul 20, 2026
AlliBalliBaba pushed a commit that referenced this pull request Jul 20, 2026
Follow-up to #2499, targeting `refactor/phpserver`. Docs-only.

The refactor introduces new public API for library users (`NewServer`,
`WithServer`, `Server.ServeHTTP`, `WithWorkerServerScope`,
`WithWorkerMatcher`) with no documentation outside godoc. This adds a
`docs/library.md` page covering:

- minimal setup: `NewServer` + `Init(WithServer(...))` +
`Server.ServeHTTP` as an `http.Handler`
- registering multiple servers (the library equivalent of multiple
`php_server` blocks)
- scoping workers to a server, by path and by request matcher
- per-request options
- the compatibility path: package-level `ServeHTTP()` keeps working
through the fallback server

Also linked from the README docs list and `llms.txt`. The examples
follow the current `NewServer` signature on the branch; if #2529 lands
first, the snippets need a one-line update (happy to rebase either way).
Translations are left to the usual translation update flow.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants