fix(agents-core): improve type safety in triggers data-access

[amikofalvy]

Summary

Replace as any casts in triggers data-access with proper type-safe conversion functions.

Changes

• Add DrizzleTriggerInsert/DrizzleTriggerSelect types inferred directly from the Drizzle schema
• Add toTriggerInsertValues() to convert Zod TriggerInsert to Drizzle-compatible insert values
• Add toTriggerUpdateValues() to convert Zod TriggerUpdate to Drizzle-compatible update values
• Add toTriggerSelect() to convert Drizzle select results to Zod-compatible TriggerSelect type

Why

The Zod types (derived from extended schemas) use .optional() which produces Type | undefined, while Drizzle expects Type | null for nullable fields. The previous code used as any casts to work around this, which:

1. Bypasses TypeScript's type checking entirely
2. Could mask real type errors
3. Makes refactoring harder

The new conversion functions:

1. Explicitly handle the undefined -> null mapping with ?? null
2. Use specific type assertions for complex JSON fields like signatureVerification
3. Preserve full type safety with Drizzle's inferred types

Testing

• All 237 agents-sdk tests pass
• Build succeeds

[changeset-bot]

⚠️ No Changeset found

Latest commit: 8c7bb45

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

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

Project	Deployment	Review	Updated (UTC)
agents-api	Ready	Preview, Comment	Jan 23, 2026 6:39am
agents-docs	Ready	Preview, Comment	Jan 23, 2026 6:39am
agents-manage-ui	Ready	Preview, Comment	Jan 23, 2026 6:39am

[claude]

Claude finished @amikofalvy's task —— View job

---

Code Review: Type Safety Improvements in Triggers Data-Access

I've analyzed this PR which replaces as any casts with proper type-safe conversion functions. Here's my comprehensive review:

✅ Positive Changes

1. Eliminates Dangerous Type Erasure

The PR successfully removes as any casts which were bypassing TypeScript's type system entirely. This is a significant improvement for type safety and developer confidence.

2. Clean Separation of Concerns

The approach of creating dedicated conversion functions (toTriggerInsertValues, toTriggerUpdateValues, toTriggerSelect) provides clear boundaries between Zod-validated external data and Drizzle's internal representation.

3. Explicit undefined → null Handling

The systematic use of ?? null makes the undefined-to-null mapping explicit and consistent, addressing the core issue where Zod types use Type | undefined while Drizzle expects Type | null.

🔍 Issues and Concerns

1. CRITICAL: Inconsistent Type Assertion Pattern

Location: Lines 34, 64, 238

signatureVerification: (data.signatureVerification ?? null) as SignatureVerificationConfig | null

Problem: While this PR eliminates as any, it introduces specific type assertions for SignatureVerificationConfig. This isn't necessarily wrong, but it's inconsistent with the goal of eliminating type assertions.

Recommendation: Consider one of these approaches:

• Define the Drizzle schema with proper typing for this field, or
• Document why this assertion is necessary (e.g., complex JSON validation)

2. Code Duplication in upsertTrigger

Location: Lines 229-239
The upsert function manually reconstructs update values instead of using toTriggerUpdateValues().

Issue: This violates DRY principles and creates maintenance burden.

Fix:

// Instead of manually constructing updateValues, use:
const updateData = {
  name: data.name,
  description: data.description,
  enabled: data.enabled,
  // ... other fields
};
const updateValues = toTriggerUpdateValues(updateData, true);

3. Missing Error Boundary in toTriggerSelect

Location: Line 74

function toTriggerSelect(row: DrizzleTriggerSelect): TriggerSelect {
  return row as TriggerSelect;
}

Concern: This still uses type assertion and assumes perfect compatibility between Drizzle and Zod types.

Recommendation: Either:

• Add runtime validation, or
• Document the type compatibility assumption with a comment explaining why this assertion is safe

4. Potential Performance Impact

The conversion functions add a layer of data transformation on every database operation. For high-throughput scenarios, consider:

• Benchmarking the performance impact
• Caching conversion results where appropriate
• Documenting any performance characteristics

🏗️ Architectural Considerations

1. Pattern Inconsistency Across Codebase

My analysis shows that other data-access files (agents.ts, projects.ts, evalConfig.ts) still use as any extensively. This creates:

• Inconsistent patterns across the codebase
• Mixed approaches to the same underlying problem
• Potential confusion for developers

Recommendation: Consider creating a follow-up task to apply this pattern consistently across all data-access modules.

2. Missing Type-Safe Builder Pattern

Consider a more systematic approach using a builder pattern or generic utility functions:

function createDrizzleConverter<TZod, TDrizzle>() {
  return {
    toInsert: (data: TZod): TDrizzle => { /* conversion logic */ },
    toUpdate: (data: Partial<TZod>): Partial<TDrizzle> => { /* conversion logic */ },
    toSelect: (row: TDrizzle): TZod => { /* conversion logic */ }
  };
}

This would make the pattern reusable and enforce consistency.

3. Transaction Boundary Considerations

The conversion functions are called within database transactions. Ensure that:

• Conversion logic doesn't perform I/O operations
• Error handling in conversions doesn't break transaction consistency
• Performance characteristics are acceptable for transaction contexts

🎯 Recommendations

High Priority

1. Fix code duplication in upsertTrigger function
2. Document or fix the signatureVerification type assertion
3. Add error handling for conversion edge cases

Medium Priority

1. Create follow-up tickets to apply this pattern to other data-access modules
2. Add unit tests specifically for the conversion functions
3. Document the pattern in team documentation for consistency

Low Priority

1. Performance benchmark the conversion overhead
2. Consider generic utilities for broader reusability

📋 Summary

This PR represents a significant improvement in type safety by eliminating dangerous as any casts. The approach is sound and the implementation is mostly well-executed. The main concerns are around consistency, code duplication, and setting a proper architectural precedent for the rest of the codebase.

The changes are ready to merge with the understanding that the noted issues should be addressed in follow-up work to maintain code quality and consistency.

Overall Assessment: ✅ Approve with follow-up recommendations

---

Todo List:

• Read and understand the modified file
• Research existing patterns in the codebase
• Analyze type safety improvements and implementation quality
• Check for architectural consistency and potential issues
• Provide comprehensive feedback