Consider softening "Connection must have a server address" from ValueError to warning when workbook has a single embedded connection

Start in request_factory.py at _add_connections_element around lines 45-46, then inspect how ConnectionItem values become connection XML. Confirm the single-connection and multi-connection cases described in the issue, and check existing tests around connection generation if present. Done means a missing server_address is allowed for one connection while the multi-connection requirement remains enforced.

Summary

_add_connections_element in request_factory.py:45-46 raises ValueError("Connection must have a server address") whenever a caller passes a ConnectionItem with no server_address. That check has been in place since TSC 0.19 (June 2022, commit 1eeaca87). Proposing that we consider softening it, or at minimum making the requirement conditional.

Why this is worth revisiting

This isn't required for workbooks with only a single connection:

• Multi-connection (federated) workbooks — server_address is genuinely needed as the matching key so Tableau Server can bind credentials to the right embedded connection. The current strict check is correct here.
• Single-connection workbooks — the workbook's TWB has exactly one <connection> element; the server can unambiguously match credentials to it. Requiring the caller to specify server_address is redundant.

Practical impact today: tabcmd Classic (--db-username/--db-password) never required a database-server flag from users, because the vast majority of published workbooks have a single embedded connection. tabcmd 2 is now being forced to add a --db-server flag (tabcmd PR #458) purely to satisfy this TSC precondition, which regresses parity with Classic and breaks existing user workflows.

Suggested options (in order of scope)

1. Warn, don't raise. Log a warning when server_address is missing and let the Tableau Server REST API reject the request if it genuinely cannot disambiguate. Server-side errors will be more informative than a client-side blanket rejection.
2. Conditional strictness. If the caller passes exactly one ConnectionItem in connections=[...], allow server_address=None and omit the attribute from the emitted <connection> XML. Require it only when len(connections) > 1.

Option (2) seems like the best balance: keeps the safety net for the ambiguous case, restores the ergonomic single-connection path.

References

• Failure surfaced by tabcmd/pull/458, which works around this by adding a new required --db-server CLI flag.
• Original tabcmd 2 feature request: tabcmd/issues/255.