Greptile Summary

This PR adds createMattermostDirectChannelWithRetry() with exponential backoff (full-jitter), per-request AbortController-based timeouts, and configurable retry options at both the account config level (dmChannelRetry in YAML) and per-call level (dmRetryOptions in MattermostSendOpts). It addresses the gap noted in PR #29925 where DM channel creation had no retry mechanism.

All nine issues raised in the previous review rounds have been resolved:

• AbortSignal is now threaded through createMattermostDirectChannel to the underlying fetch
• onRetry callback is now preserved via a wrapper that delegates to the caller's callback before logging
• initialDelayMs <= maxDelayMs cross-field validation is enforced by Zod .refine()
• isRetryableError checks 5xx before 4xx and anchors patterns to "mattermost api" prefix, preventing port numbers and IP octets from triggering false classifications
• Jitter is now proportional to exponentialDelay rather than a fixed 1000 ms
• MattermostAccountConfig in types.ts now includes dmChannelRetry
• The timeout test was rewritten to actually exercise the AbortController abort path

One design point from the previous round (full replacement via ?? rather than field-level merging of opts.dmRetryOptions with accountRetryConfig) was noted but appears to be an intentional design decision — callers who provide any dmRetryOptions are expected to supply all relevant fields they want to control.

Confidence Score: 4/5

• This PR is safe to merge — all previously flagged issues have been addressed and the retry/timeout logic is correctly implemented.
• All nine issues from prior review rounds are resolved: AbortSignal is forwarded, onRetry is preserved, jitter is proportional, isRetryableError ordering and anchoring are correct, cross-field Zod validation is present, and the type declaration is in sync. Tests are comprehensive and cover the corrected edge cases. The one remaining design point (full replacement via ?? rather than field-level merge) was already flagged in a previous thread and appears intentional. No new critical issues found.
• No files require special attention — the key logic in client.ts and send.ts looks correct after all the fixes.

_{Last reviewed commit: eaaf224}

@greptile-apps Thanks for the thorough review! All four issues have been addressed in commit 8a23919:

1. timeoutMs non-functional ✅ Fixed - controller.signal is now passed through createMattermostDirectChannel to the underlying fetch

2. isRetryableError false positives ✅ Fixed - Added explicit 4xx check before network pattern matching. Any message containing a 4xx status code (except 429) returns false before reaching the pattern list

3. onRetry silently dropped ✅ Fixed - Now calls both user's callback and logger (if verbose): params.dmRetryOptions?.onRetry?.(attempt, delayMs, error) then logger

4. initialDelayMs > maxDelayMs ✅ Fixed - Added Zod .refine() with clear error message

Also added 3 new tests to verify the 4xx false positive fixes and AbortSignal propagation.

Perfect! All four issues are properly fixed:

1. timeoutMs ✅ - AbortSignal is now correctly passed through the entire chain (client.ts:188-193, 169-173)

2. isRetryableError false positives ✅ - Two layers of protection:

• Explicit 4xx check before pattern matching (client.ts:217-225)
• Additional safeguard that rejects any message with a 3-digit HTTP status before checking network patterns (client.ts:232-236)

3. onRetry callback ✅ - User callback is preserved and called before logging (send.ts:176-177)

4. initialDelayMs validation ✅ - Zod refinement with clear error message (config-schema.ts:17-25)

The new tests comprehensively cover the edge cases. Nice work!

Hi maintainers, Greptile's review was on an older commit (c177c1d). All issues have been fixed in the latest commit (8a23919). Could someone please re-trigger Greptile or do a manual review? Thanks!

关闭原因：发现多个严重 bug 需要重新设计

1. timeoutMs 功能完全不工作 - AbortController signal 未传递给 fetch
2. isRetryableError 逻辑错误 - 会错误重试包含关键词的 4xx 错误
3. onRetry 回调在非 verbose 模式下被静默丢弃
4. Schema 允许无效配置（initialDelayMs > maxDelayMs）

请修复后重新提交。

🔴 发现严重问题，建议关闭此 PR

关键 Bug：

1. timeoutMs 功能完全不工作

   • AbortController 的 signal 没有传递给 fetch 调用

2. isRetryableError 逻辑错误

   • 会错误地重试包含 "timeout" 或 "abort" 关键词的 4xx 错误

3. onRetry 回调被静默丢弃

   • 关闭 verbose 日志后，回调不会执行

4. Schema 验证缺失

   • 允许 initialDelayMs > maxDelayMs 这种无效配置

建议重新设计后再提交。

@greptile review

Merged via squash.

• Prepared head SHA: 3db47be907decd78116603c6ab4a48ff91eb2c25
• Merge commit: 2145eb5908c0f625988f2d284db1762ee3af024e

Thanks @JonathanJing!