Problem

HandlerArgs.swift 的 int64ArgValue helper 保留了舊 handler 的行為——除了 .int(...) 外也支援 .string("123") 形式的數字字串：

private func int64ArgValue(_ args: [String: Value], _ key: String) -> Int64? {
    guard let value = args[key] else { return nil }
    if let n = value.intValue { return Int64(n) }
    if let s = value.stringValue { return Int64(s) }
    return nil
}

但 ServerHandlerLogicTests 沒有測這條 backward-compat 路徑。

From verification of #7 by Codex:
「舊 handler 支援數字字串形式的 chat_id / from_message_id，新 helper 也保留了這個行為，但目前測試沒有明確覆蓋這條相容性。」

Type

enhancement

Expected

加 test case 驗證：

• {"chat_id": .string("100")} → chatId == 100
• {"from_message_id": .string("12345")} → fromMessageId == 12345
• {"chat_id": .string("not-a-number")} → throws (required field invalid)

避免未來有人重構 int64ArgValue 時不小心拿掉 string fallback。

Code Reference

• Sources/CheTelegramAllMCPCore/HandlerArgs.swift:72-78

Related: #7

Current Status

Phase: closed
Last updated: 2026-04-27 by idd-close

Key Decisions

• 4 個 tests（plan 寫 3，加 dump parity 1）
• .string("not-a-number") 走 silent → nil → required-field 路徑（int64ArgValue 設計）— DA 反駁 misleading message，opened follow-up chat_id type-mismatch error message misleads (silently shows 'is required' instead of type error) #22 修 UX
• 6-AI verify: PASS

Scope Changes

• +1 dump parity test（testDumpChatIdAsStringAccepted）

Blocking

(none)

Test counts

• 156 → 160 (+4) → 163 after MCP handler 型別強制 + CLI parity: max_messages string bypass + CLI date behavior 不一致 #8 verify-DA fix
• All pass
• Codex independent: 34 ServerHandlerLogicTests pass

Commits

• 2219206 test: lock backward-compat numeric-string chat_id/from_message_id (Test: backward-compat numeric-string chat_id / from_message_id parsing #12)

Follow-up

• chat_id type-mismatch error message misleads (silently shows 'is required' instead of type error) #22 — chat_id type-mismatch error message misleads (DA F4)