fix: priority decrease on project task creation

[fblgit]

fix: priority decrease on project task creation

[claude]

Claude finished @fblgit's task —— View job

---

✅ PR Review Complete

I've posted a comprehensive review of the priority cascade implementation. The changes improve task prioritization but have some considerations for edge cases with many subtasks.

Review Summary:

• ✅ Code follows repository conventions
• ✅ Performance is optimal
• ✅ No security issues
• ⚠️ Priority exhaustion with 10+ subtasks
• 💡 Suggested dependency-aware priority assignment

The full detailed review has been posted as a comment on the PR.

[claude]

Code Review: Priority Cascade Implementation

I've reviewed the changes in PR #17 that implements cascading priority for project task creation. Here's my comprehensive feedback:

✅ Code Quality & Best Practices

The implementation follows the repository's conventions well:

• Adheres to the handler-centric design pattern from CLAUDE.md
• Maintains the <50 lines rule for readability
• Uses proper TypeScript types and interfaces
• Follows the event-driven architecture correctly

🔍 The Change

The PR modifies the priority assignment logic for subtasks:

Before: All subtasks received priority = max(10, parent_priority - 10)
After: Subtasks receive cascading priority: priority = max(5, parent_priority - 5 - (index * 5))

⚠️ Potential Issues

1. Priority Exhaustion: With many subtasks, priorities could quickly reach the minimum of 5. For a project with priority 50:

   • 1st subtask: 45
   • 5th subtask: 25
   • 9th subtask: 5 (minimum)
   • 10th+ subtasks: all get 5

   Recommendation: Consider a logarithmic or percentage-based decay instead of linear -5 decrements.

2. Dependency Order Mismatch: The priority assignment uses array iteration order, but subtasks have explicit dependencies. Tasks with dependencies on higher-priority tasks might execute out of order.

   Recommendation: Consider topological sorting based on dependencies before assigning priorities.

🚀 Performance Considerations

• The change is performant - single pass through subtasks with O(1) operations
• No additional Redis calls or database queries
• Memory usage remains constant

🔒 Security Assessment

• No security concerns identified
• Input validation remains intact via Zod schemas
• No exposure of sensitive data

🧪 Test Coverage Implications

The change would benefit from:

1. Contract test to verify priority values in the API response
2. Integration test to confirm Redis queue ordering matches priority cascade
3. Edge case test for projects with 20+ subtasks hitting minimum priority

💡 Suggestions for Future Improvements

1. Make the priority decrement configurable (currently hardcoded to 5)
2. Add a priorityStrategy option to the input schema (e.g., 'cascade', 'uniform', 'dependency-based')
3. Log a warning when multiple tasks hit the minimum priority threshold
4. Consider dependency-aware priority assignment using topological sort

✅ Overall Assessment

The implementation correctly addresses the priority issue and maintains code quality. The cascading approach is a good improvement over the flat priority assignment. However, consider the edge cases mentioned above for projects with many subtasks.

The change is production-ready but would benefit from the suggested test coverage additions.

---

🤖 Generated with Claude Code