Control characters in table names break all S3 list operations

[khalid244]

Problem

Table/measurement names containing ASCII control characters (0x01-0x08, 0x0B-0x0C, 0x0E-0x1F) cause S3 listing to
fail. These characters are illegal in XML 1.0 and corrupt the ListObjectsV2 response.

Error

{
"error": "Failed to list databases: failed to list S3 objects: operation error S3: ListObjectsV2,
https response error StatusCode: 200, deserialization failed,
XML syntax error on line 1: illegal character code U+0005"
}

Affected Endpoints

• GET /api/v1/databases
• Any endpoint that lists S3 objects

Broken Characters

0x01-0x08, 0x0B, 0x0C, 0x0E-0x1F (all control chars except TAB, LF, CR)

Impact

One bad table name breaks all database/table listing for the entire bucket until manually deleted from S3.

Fix

Reject table names with control characters on write:
for _, r := range name {
if r < 0x20 && r != '\t' && r != '\n' && r != '\r' {
return fmt.Errorf("invalid character U+%04X in name", r)
}
}

Repro

aws s3 cp test.parquet "s3://bucket/db/table$(printf '\x05')name/test.parquet"
curl http://localhost:8000/api/v1/databases # fails

Environments

• Arc 26.01.2
• Hetzner S3

[xe-nvdk]

Thanks for the detailed report @khalid244!

You're right - this is a critical issue where one bad measurement name can break all S3 listing operations. The fix has been committed in 95d7326.

What we changed

We added measurement name validation across all write paths:

1. Line Protocol (POST /api/v1/write)
2. MsgPack (POST /api/v1/write/msgpack)
3. Continuous Queries (create and update)

Measurement names now follow the same validation pattern as database names:

• Must start with a letter (a-zA-Z)
• Can only contain alphanumeric characters, underscores, or hyphens (a-zA-Z0-9_-)
• Max 128 characters

This is stricter than just rejecting XML-illegal control characters, but it:

• Matches existing database name validation for consistency
• Prevents future issues with special characters in file paths, URLs, etc.
• Follows a "safe by default" approach

Example error response

{
  "error": "invalid measurement name \"test\u0005name\": must start with a letter and contain only alphanumeric characters, underscores, or hyphens"
}

Note on overhead

The validation regex is compiled once at startup, so the per-request overhead is minimal (single regex match on short strings).

Let us know if this works for your use case or if you need the looser validation approach!

[xe-nvdk]

Update: This fix will be shipped in Arc 26.02.1 (February 2026 release).