fix(convex): add messageStatusValidator for stricter message status validation

[larryro]

Summary

• Created messageStatusValidator union validator for stricter type safety on message status field
• Replaced permissive v.string() with union of valid delivery states: queued, sent, delivered, failed
• Exported new MessageStatus type from types.ts

Context

Addresses CodeRabbit comment #2652223400 from PR #37 review, which identified that messageValidator was using v.string() for the status field, allowing any string value instead of enforcing valid message statuses.

Test plan

• Verify TypeScript compilation passes
• Confirm message status values align with schema deliveryState definition
• Test conversation message display in UI still works correctly

Summary by CodeRabbit

• Chores
  • Enhanced message delivery state handling with stricter validation across the system.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Two validation and type files were updated to introduce stricter message status validation. A new messageStatusValidator was added to the validators module that defines allowed message delivery states (queued, sent, delivered, failed). A corresponding type alias MessageStatus was created in the types module by inferring from this validator. The messageValidator was updated to use the new validator for its status field instead of accepting any string, tightening the validation constraints.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Possibly related issues

• Add messageStatusValidator for stricter message status validation #39: Introduces messageStatusValidator and updates messageValidator.status to reference it, tightening allowed message status values to a specific union type.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro (Legacy)

📥 Commits

Reviewing files that changed from the base of the PR and between 9c2e381 and 47d371c.

📒 Files selected for processing (2)

• services/platform/convex/model/conversations/types.ts
• services/platform/convex/model/conversations/validators.ts

🧰 Additional context used

🧠 Learnings (9)

📓 Common learnings

Learnt from: larryro
Repo: tale-project/tale PR: 37
File: services/platform/convex/model/conversations/validators.ts:31-39
Timestamp: 2025-12-30T06:20:14.869Z
Learning: In services/platform/convex/model/conversations/validators.ts, the messageValidator intentionally uses v.string() for the status field because message statuses are dynamic and come from different sources (email providers, internal state, etc.) and are not yet constrained to a fixed set of values.

Learnt from: larryro
Repo: tale-project/tale PR: 37
File: services/platform/convex/model/conversations/validators.ts:106-139
Timestamp: 2025-12-30T06:20:39.422Z
Learning: In services/platform/convex/model/conversations/validators.ts, conversationItemValidator and conversationWithMessagesValidator are intentionally kept as separate validators despite having identical structures. This separation serves different semantic purposes: conversationItemValidator is for list responses while conversationWithMessagesValidator is for single conversation detail views. The duplication allows future divergence when list views might need different fields than detail views for performance or feature reasons.

📚 Learning: 2025-12-30T06:20:14.869Z

Learnt from: larryro
Repo: tale-project/tale PR: 37
File: services/platform/convex/model/conversations/validators.ts:31-39
Timestamp: 2025-12-30T06:20:14.869Z
Learning: In services/platform/convex/model/conversations/validators.ts, the messageValidator intentionally uses v.string() for the status field because message statuses are dynamic and come from different sources (email providers, internal state, etc.) and are not yet constrained to a fixed set of values.

Applied to files:

• services/platform/convex/model/conversations/types.ts
• services/platform/convex/model/conversations/validators.ts

📚 Learning: 2025-12-30T06:20:39.422Z

Learnt from: larryro
Repo: tale-project/tale PR: 37
File: services/platform/convex/model/conversations/validators.ts:106-139
Timestamp: 2025-12-30T06:20:39.422Z
Learning: In services/platform/convex/model/conversations/validators.ts, conversationItemValidator and conversationWithMessagesValidator are intentionally kept as separate validators despite having identical structures. This separation serves different semantic purposes: conversationItemValidator is for list responses while conversationWithMessagesValidator is for single conversation detail views. The duplication allows future divergence when list views might need different fields than detail views for performance or feature reasons.

Applied to files:

• services/platform/convex/model/conversations/types.ts
• services/platform/convex/model/conversations/validators.ts

📚 Learning: 2025-12-15T14:44:09.823Z

Learnt from: larryro
Repo: tale-project/tale PR: 18
File: services/platform/convex/workflow/actions/conversation/conversation_action.ts:47-98
Timestamp: 2025-12-15T14:44:09.823Z
Learning: In Convex action files (services/platform/convex/workflow/actions/**/), maintaining a separate TypeScript type alongside the parametersValidator is an acceptable pattern when documented. The TypeScript type provides IDE support and compile-time checking, while the validator provides runtime validation. This intentional separation should be documented with a comment explaining the design choice.

Applied to files:

• services/platform/convex/model/conversations/types.ts
• services/platform/convex/model/conversations/validators.ts

📚 Learning: 2025-10-03T11:34:20.628Z

Learnt from: CR
Repo: talecorp/poc2 PR: 0
File: .cursor/rules/convex_rules.mdc:0-0
Timestamp: 2025-10-03T11:34:20.628Z
Learning: Applies to convex/**/*.{ts,js} : Use the documented Convex validators for all supported types (e.g., v.id, v.int64, v.number, v.boolean, v.string, v.bytes, v.array, v.object, v.record)

Applied to files:

• services/platform/convex/model/conversations/types.ts
• services/platform/convex/model/conversations/validators.ts

📚 Learning: 2025-12-26T03:04:07.995Z

Learnt from: larryro
Repo: tale-project/tale PR: 35
File: services/platform/convex/approvals.ts:51-62
Timestamp: 2025-12-26T03:04:07.995Z
Learning: In Convex approvals API (services/platform/convex/approvals.ts), continue the pattern of maintaining separate internalQuery functions for internal vs public API access (e.g., getApprovalInternal vs getApprovalById) even if implementations are identical. This separation preserves the ability to diverge access control patterns in the future without breaking call sites. Apply this guideline broadly to the Convex-related API files under services/platform/convex/, using the pattern services/platform/convex/**/*.ts to cover similar modules. Ensure new or refactored internal/public wrappers follow this convention and document intent where access rules may evolve.

Applied to files:

• services/platform/convex/model/conversations/types.ts
• services/platform/convex/model/conversations/validators.ts

📚 Learning: 2025-12-30T03:24:33.770Z

Learnt from: larryro
Repo: tale-project/tale PR: 36
File: services/platform/convex/wf_step_defs.ts:33-39
Timestamp: 2025-12-30T03:24:33.770Z
Learning: In Convex API files under services/platform/convex (e.g., wf_step_defs.ts and peers) refrain from delegating trivial single-line database calls like ctx.db.get(id) to model helpers. Use direct calls for simple operations with no extra business logic. Reserve model helpers for complex tasks (ordering, filtering, validation, transformation). This guideline applies to all .ts files in this Convex API area.

Applied to files:

• services/platform/convex/model/conversations/types.ts
• services/platform/convex/model/conversations/validators.ts

📚 Learning: 2025-12-30T06:21:13.183Z

Learnt from: larryro
Repo: tale-project/tale PR: 37
File: services/platform/convex/model/documents/validators.ts:89-102
Timestamp: 2025-12-30T06:21:13.183Z
Learning: Do not flag a missing trailing newline for TypeScript files in code reviews. POSIX text files should end with a trailing newline and Prettier (or your formatter) will enforce this. Treat the trailing newline as a non-issue in reviews for all TS files.

Applied to files:

• services/platform/convex/model/conversations/types.ts
• services/platform/convex/model/conversations/validators.ts

📚 Learning: 2025-11-30T03:53:00.316Z

Learnt from: CR
Repo: tale-project/poc2 PR: 0
File: .cursor/rules/convex_rules.mdc:0-0
Timestamp: 2025-11-30T03:53:00.316Z
Learning: Applies to convex/**/*.ts : Always include argument and return validators for all Convex functions (query, internalQuery, mutation, internalMutation, action, internalAction)

Applied to files:

• services/platform/convex/model/conversations/validators.ts

🧬 Code graph analysis (1)

services/platform/convex/model/conversations/types.ts (1)

services/platform/convex/model/conversations/validators.ts (1)

• messageStatusValidator (32-37)

🔇 Additional comments (2)

services/platform/convex/model/conversations/types.ts (1)

15-15: LGTM! Type definition follows established patterns.

The import and type export are correctly structured and consistent with existing patterns in this file.

Also applies to: 25-25

services/platform/convex/model/conversations/validators.ts (1)

28-37: The validator formalization is not a breaking change. The database schema (schema.ts:520-524) already constrains deliveryState to these same 4 values, and all code paths across email providers, workflows, and message handlers consistently use only these values. No existing data or writers would be affected by this validator change.

Likely an incorrect or invalid review comment.

[larryro]

Addressed CodeRabbit's nitpick comment in commit 5233bf1:

• Updated the doc comment for messageStatusValidator to correctly reference "message status field" instead of "deliveryState field" for clarity, as suggested by CodeRabbit.