Uh oh!
There was an error while loading. Please reload this page.
Fix azurite-table banner reporting configured port instead of bound port - #2643
Conversation
The standalone azurite-table entry point printed its "successfully started" banner using the configured port from `config.port`. When a caller passes `--tablePort 0` to request an OS-assigned port, this caused the banner to report port 0 instead of the actual bound port, breaking any tooling that parses the banner to discover where the service is listening (e.g. Storage Explorer, test harnesses that need to construct a connection string). The blob and queue entry points already use `server.getHttpServerAddress()` for this message; align table to match. The wording is also normalized from "successfully started on" to "successfully listens on" for consistency with blob and queue.
Robert McLaws (@robertmclaws) , could you please refresh your PR with main, and address the review comments if any to move this PR forward. |
There was a problem hiding this comment.
Pull request overview
This PR fixes the azurite-table standalone startup banner so it reports the actual bound address after server.start() (important when --tablePort 0 is used for OS-assigned ports), and aligns the banner wording with the blob/queue entry points.
Changes:
- Update
src/table/main.tsto print the post-start banner usingserver.getHttpServerAddress()afterawait server.start(). - Normalize the table banner wording from “successfully started on” to “successfully listens on” to match other services.
- Document the fix under the “Upcoming Release” section in
ChangeLog.md.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/table/main.ts | Prints the post-start banner using the bound address via server.getHttpServerAddress() after start. |
| ChangeLog.md | Adds an Upcoming Release note describing the corrected table startup banner behavior. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Uh oh!
There was an error while loading. Please reload this page.
Summary
azurite-tableentry point printed its "successfully started" banner usingconfig.portevaluated beforeserver.start(), so callers passing--tablePort 0sawport: 0instead of the actual OS-assigned port.azurite-blobandazurite-queuealready inlineserver.getHttpServerAddress()afterawait server.start(); this PR brings table to parity.Fixes#2642. Related: #145 (the original OS-assigned port feature this bug defeated for table-only callers), #2347 (table-only Storage Explorer connectivity — the divergent banner wording is the most visible symptom of the same code-path inconsistency).
Diff
Test plan
npm run lintpassesnpm run build(tsc) passes--tablePort 0:--tablePort 12345(explicit port still works):"successfully started on"wording (grep -rn "successfully started" tests/is empty for this string).