fix(ses): reject malformed startDate/endDate in list_suppressed_destinations

[waleedlatif1]

Summary

• Follow-up to feat(aws): expand SES/STS/Secrets Manager tool coverage, fix API alignment gaps #5450 — one review-round fix (Cursor round 6) got pushed to the source branch after that PR was already squash-merged, so it never landed on staging
• ses_list_suppressed_destinations's startDate/endDate were passed through new Date(...) with no validity check; a malformed non-empty string became an Invalid Date and was still forwarded to AWS, surfacing as a generic 500 instead of a clear 400
• Fixed at the contract level with a Zod refine rejecting unparseable date strings

Type of Change

• Bug fix

Testing

• bunx tsc --noEmit, bun run lint, bun run check:api-validation all pass
• Verified this is the only diff vs current staging (single-file, 12 insertions/2 deletions)

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Jul 7, 2026 1:50am

[cursor]

PR Summary

Low Risk
Single-file input validation on optional query parameters; no auth, data model, or AWS call logic changes beyond rejecting bad dates earlier.

Overview
ses_list_suppressed_destinations now validates optional startDate and endDate at the API contract layer before the request reaches AWS.

Each field keeps nullish behavior, but non-empty values must parse as real dates via a Zod refine (!Number.isNaN(new Date(v).getTime())). Invalid strings return a 400 with explicit messages instead of flowing through as Invalid Date and failing as a generic 500 from SES.

^{Reviewed by Cursor Bugbot for commit 0b31838. Configure here.}

[greptile-apps]

Greptile Summary

Adds contract-level Zod refine guards to startDate and endDate in the ses_list_suppressed_destinations schema, so that malformed non-empty date strings (e.g. "not-a-date") are rejected with a clean 400 instead of propagating as Invalid Date to the AWS SES SDK.

• Contract fix (ses-list-suppressed-destinations.ts): .string().nullish().refine((v) => !v || !Number.isNaN(new Date(v).getTime()), ...) is applied to both date fields. The !v guard correctly short-circuits for null, undefined, and empty-string — all three are treated as "no filter" by the downstream route, so they never reach the SDK as an invalid value.
• No route-handler change needed: the fix is entirely at the schema/contract layer, which is the right place for input validation in this codebase.

Confidence Score: 5/5

Single-file validation tightening; no behavioral change for valid or absent dates, and malformed inputs are now correctly stopped at the schema layer.

The change is minimal and targeted: two Zod field definitions gain a refine predicate using Number.isNaN(new Date(v).getTime()), a well-established JS idiom. The !v short-circuit is correct given the downstream route's own falsy guard. No existing valid call-site behavior is affected, and the fix directly prevents the Invalid Date propagation the PR describes.

No files require special attention.

Important Files Changed

Filename	Overview
apps/sim/lib/api/contracts/tools/aws/ses-list-suppressed-destinations.ts	Adds Zod .refine() guards on startDate/endDate to reject unparseable date strings with a 400 before they reach the AWS SDK; the !v short-circuit correctly passes through null/undefined/empty-string, all safely handled as no-filter in the downstream route.

_{Reviews (2): Last reviewed commit: "fix(ses): reject malformed startDate/end..." | Re-trigger Greptile}

[waleedlatif1]

@greptile please re-review

[waleedlatif1]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 0b31838. Configure here.}