feat: handle consumption request of iap cores purchase

[omBratteng]

When we receive a consumption request for an IAP cores purchase, we must send consumption information to Apple.

https://dailydotdev.slack.com/archives/C07LHS7RXA4/p1762863856813219

[omBratteng]

@claude review this pl0x as a 1337 h3x0r

[claude]

Claude finished @omBratteng's task —— View job

---

Code Review: IAP Cores Purchase Consumption Request 🚀

This PR implements handling for consumption requests from Apple's App Store for in-app purchase cores. The implementation looks solid overall with good error handling and type safety. Here are my findings:

✅ Strengths

1. Well-structured implementation - Clean separation of concerns between purchase handling and consumption request handling
2. Comprehensive type safety - Good use of TypeScript interfaces and Apple's SDK types
3. Proper error handling - Graceful handling of missing required fields with descriptive error messages
4. Security considerations - Proper validation of user access and app account tokens
5. Infrastructure configuration - Apple credentials are properly configured in Pulumi

🔍 Key Implementation Details

New Function: handleCoresConsumptionRequest in src/common/apple/purchase.ts:303-360

• Validates transaction ID and app account token
• Checks delivery status by querying existing UserTransaction records
• Sends consumption data to Apple with appropriate status flags
• Uses proper Apple SDK client with production environment support

Webhook Enhancement: Added CONSUMPTION_REQUEST handling in src/routes/webhooks/apple.ts:139-144

• Integrates seamlessly with existing webhook notification flow
• Proper type checking for consumable transactions

🤔 Questions & Suggestions

1. Account Tenure Logic (src/common/apple/utils.ts:161-177):

   export const getAccountTenure = (user: Pick<User, 'createdAt'>): number => {

   The function returns 0 if user.createdAt is falsy. Should this be logged as a warning since account tenure is important for Apple's fraud detection?

2. Delivery Status Logic (src/common/apple/purchase.ts:330-344):

   const deliveryStatus = await con.getRepository(UserTransaction).exists({
     where: {
       receiverId: user.id,
       flags: JsonContains({ providerId: transactionInfo.transactionId }),
     },
   });

   This logic assumes successful delivery if a UserTransaction exists. Should we also check the transaction status to ensure it was actually successful?

3. Error Handling: What happens if apiClient.sendConsumptionData() fails? Should we log this failure or retry?

4. Testing: Are there plans to add tests for the new consumption request flow?

🔧 Minor Observations

• Type Definitions (src/types.ts:74-78): Good addition of Apple-related environment variables to the ProcessEnv interface
• Infrastructure (.infra/Pulumi.prod.yaml): Apple credentials are properly secured and configured
• Code Style: Follows existing patterns and conventions well

🎯 Overall Assessment

This is a well-implemented feature that properly integrates with Apple's consumption request system. The code follows the repository's patterns for type safety, error handling, and architectural conventions. The implementation correctly handles the consumption request workflow by:

1. Validating required data
2. Checking delivery status based on existing transactions
3. Sending appropriate consumption information to Apple
4. Using proper security measures

Recommendation: ✅ Approved - This implementation looks production-ready with good adherence to best practices.

---