[Bug]: Table detail navigation fails for table names containing "#" or non-ASCII characters (i18n)

[tadmas2020]

Description

Clicking a table name in the table list does not open the detail page. This happens when the table name contains #, other URL-reserved characters, or non-ASCII characters. The scan itself succeeds and the table appears in the list.

Environment

• Commit ID: Observed on 42b5c6b (tag v0.2.2). The code is still unchanged on e265573 (tag v0.3.1 = main).
• Environment: ap-northeast-1 deployment

Step to reproduce

• Register a data source with a table whose name contains # (for example SALES#2026)
• Run a scan and confirm it completes successfully
• Confirm the table appears in the table list on the Source detail page
• Click the table name link
• The detail page does not open. The browser URL stops at .../tables/SALES and everything from #2026 onward is treated as a fragment.

A root cause

The navigation URL is built from the raw tableId. # is interpreted as the start of a URL fragment, so the path is cut there and no longer matches the React Router route /namespaces/:namespaceId/sources/:dataSourceId/tables/:tableId.

packages/web-app/src/pages/SourceDetail.tsx

<Link
  onFollow={(e) => {
    e.preventDefault();
    navigate(
      `/namespaces/${namespaceId}/sources/${sourceId}/tables/${item.tableId}`,
    );
  }}
>
  {item.tableId}
</Link>

Two changes are needed.

1. Encode tableId with encodeURIComponent.
2. Extract the URL construction into a helper. There is only one such call site today, but the same omission will recur once more navigation paths are added.

const tableDetailPath = (
  namespaceId: string,
  sourceId: string,
  tableId: string,
): string =>
  `/namespaces/${encodeURIComponent(namespaceId)}` +
  `/sources/${encodeURIComponent(sourceId)}` +
  `/tables/${encodeURIComponent(tableId)}`;

navigate(tableDetailPath(namespaceId!, sourceId!, item.tableId!));

Both the useParams return values and TableSummary.tableId are optional, so the call site takes the same shape as the existing code in this file that passes namespaceId! / sourceId! / t.tableId! to ReviewSourceTableCommand.

Context

The API side already decodes path parameters: _route() in sources_handler.py unquotes pathParameters in one place (its comment uses db.商品マスタ as the example). The UI-side encodeURIComponent is the counterpart, and only the UI side is missing.

Risks & Known Unknowns

• Existing bookmarked URLs are essentially unaffected. Un-encoded URLs never worked for tables containing # in the first place.
• API calls are encoded independently by the Smithy client (GetSourceTableCommand) and unquoted on the Lambda side. That path is separate from the browser URL, so double encoding is not expected, but this needs verification on a live deployment.

Additional Information / References

• Related: [Bug]: A schema with Japanese column names cannot be queried through Tier 2 #165 (Japanese column names collide in the R2RML PredicateObjectMap and the VKG fails to load. The symptom there is a Tier-2 query failure, which is a different issue.)
• Related: [Bug]: A scan fails for a Snowflake host name containing an underscore #178 mentions in its body that "The same step also rejects a non-ASCII database name"

[tadmas2020]

The impact turns out to be wider than #194 describes. Everything below is resolved by the fix in #194 — recording it for completeness.

Japanese alone is enough to break it

Table names without # fail too. Clicking NEC.T_売上集計 produces the same error. #194 leads with # and treats non-ASCII as secondary, but a Japanese-named table cannot be opened whether or not it contains #.

The two break differently.

• # — interpreted as the start of a URL fragment, so the path is cut there. Only NEC.売上 reaches the server.
• Japanese — the browser percent-encodes it automatically, so the full name reaches the server. It breaks because the server side never decodes it.

On v0.2.2, Approve fails as well

Approving from the table list also fails (0 of 2 approved. 2 failed). On v0.2.2, a Japanese-named table can therefore neither be viewed nor approved, and never reaches Induction or Playground.

Approve takes a different path from the browser URL: SourceDetail.tsx passes tableId to ReviewSourceTableCommand, the Smithy client encodes it, and the Lambda side unquotes it. That path failed on v0.2.2 because the API side had no unquote, and it was fixed in v0.3.0.

Correction to the Risks section of #194

#194 states:

API calls are encoded independently by the Smithy client (GetSourceTableCommand) and unquoted on the Lambda side. That path is separate from the browser URL, so double encoding is not expected

Double encoding still does not occur, but the wording reads as "separate, therefore fine". In fact that separate path was itself failing on v0.2.2 — a different problem that the UI-side encodeURIComponent does not address.

Against v0.3.1 the API side is already fixed, so the scope of the fix in #194 is unchanged. The missing UI-side encodeURIComponent remains the open item, as before.

In summary

Even after the v0.3.1 fix, a table whose name contains Japanese characters or # can be put through the Approve action, but its detail page cannot be opened and its contents cannot be inspected.

Approve runs from checkboxes in the list, so the only thing available at approval time is the table name and its types. There is no way to review the AI-generated descriptions or the inferred primary and foreign keys. The COA review flow puts the PENDING_REVIEW → APPROVED transition there precisely so a human can check what the AI produced; for Japanese-named tables that check is skipped.

	v0.2.2	v0.3.1 (#194 unfixed)	After #194
Open the detail page	no	no	yes
Approve	no	yes	yes
Induction	no	yes	yes