azurite-table reports configured port (0) in startup banner instead of OS-bound port

[robertmclaws]

Which service(s)

Table

Which version of Azurite was used

Latest main (verified at commit b6298b2)

Where do you get Azurite

npm (azurite-table standalone entry point)

What problem was encountered

When the standalone azurite-table entry point is run with --tablePort 0 (asking the OS to assign an unused port — supported since #145), the startup banner reports 0 instead of the actual bound port:

Azurite Table service is starting on 127.0.0.1:0
Azurite Table service successfully started on 127.0.0.1:0    ← reports configured port, not bound port

The blob and queue entry points correctly use server.getHttpServerAddress() for the "after start" message and report the real bound address, e.g.:

Azurite Blob service successfully listens on http://127.0.0.1:57443
Azurite Queue service successfully listens on http://127.0.0.1:57444

This breaks any consumer that parses the banner to discover where the table service is listening — including:

• The dynamic-port scenario originally requested in Allow server instances to run on OS-assigned unused ports #145 (test harnesses spinning up parallel Azurite instances).
• Tooling like Storage Explorer, which appears to be related to Cannot connect to emulator in azure storage explorer when only running table service #2347 ("Cannot connect to emulator in azure storage explorer when only running table service") — the table-only banner is the only one whose wording differs from blob/queue.

Root cause

src/table/main.ts builds the banner from configuration values, before server.start() runs:

https://github.com/Azure/Azurite/blob/b6298b2/src/table/main.ts#L62-L63

const beforeStartMessage = `Azurite Table service is starting on ${config.host}:${config.port}`;
const afterStartMessage = `Azurite Table service successfully started on ${config.host}:${config.port}`;

src/blob/main.ts and src/queue/main.ts instead inline the message at print time and use server.getHttpServerAddress(), which returns the real bound address after listen() resolves:

https://github.com/Azure/Azurite/blob/b6298b2/src/blob/main.ts#L41-L47
https://github.com/Azure/Azurite/blob/b6298b2/src/queue/main.ts#L87-L93

The TableServer.afterStart() hook (src/table/TableServer.ts:104-107) already logs the correct value via logger.info, but main.ts prints the wrong one to stdout.

Steps to reproduce

node dist/src/table/main.js --inMemoryPersistence --silent --tablePort 0

Expected:

Azurite Table service is starting on 127.0.0.1:0
Azurite Table service successfully listens on http://127.0.0.1:<actual-port>

Actual:

Azurite Table service is starting on 127.0.0.1:0
Azurite Table service successfully started on 127.0.0.1:0

Have you found a mitigation/solution

Yes — fix submitted as a PR which mirrors the inline getHttpServerAddress() pattern from blob/main.ts and queue/main.ts.

Related issues

• Allow server instances to run on OS-assigned unused ports #145 — original request to support OS-assigned (port 0) listening; the bug here defeats that scenario for table-only.
• Cannot connect to emulator in azure storage explorer when only running table service #2347 — Storage Explorer cannot connect when running table-only; the inconsistent banner wording (started on vs blob/queue's listens on) is the most visible symptom of the same code path divergence and may be related.