feat: implement 8 OpenSpec proposals for security, reliability, and UX improvements
## Security Enhancements (P0) - Add input validation with max_length and numeric range constraints - Implement WebSocket token authentication via first message - Add path traversal prevention in file storage service ## Permission Enhancements (P0) - Add project member management for cross-department access - Implement is_department_manager flag for workload visibility ## Cycle Detection (P0) - Add DFS-based cycle detection for task dependencies - Add formula field circular reference detection - Display user-friendly cycle path visualization ## Concurrency & Reliability (P1) - Implement optimistic locking with version field (409 Conflict on mismatch) - Add trigger retry mechanism with exponential backoff (1s, 2s, 4s) - Implement cascade restore for soft-deleted tasks ## Rate Limiting (P1) - Add tiered rate limits: standard (60/min), sensitive (20/min), heavy (5/min) - Apply rate limits to tasks, reports, attachments, and comments ## Frontend Improvements (P1) - Add responsive sidebar with hamburger menu for mobile - Improve touch-friendly UI with proper tap target sizes - Complete i18n translations for all components ## Backend Reliability (P2) - Configure database connection pool (size=10, overflow=20) - Add Redis fallback mechanism with message queue - Add blocker check before task deletion ## API Enhancements (P3) - Add standardized response wrapper utility - Add /health/ready and /health/live endpoints - Implement project templates with status/field copying ## Tests Added - test_input_validation.py - Schema and path traversal tests - test_concurrency_reliability.py - Optimistic locking and retry tests - test_backend_reliability.py - Connection pool and Redis tests - test_api_enhancements.py - Health check and template tests Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
beabigegg
@@ -0,0 +1,17 @@
|
||||
# Change: Add Concurrency Handling and Reliability Improvements
|
||||
|
||||
## Why
|
||||
Multiple users editing the same task simultaneously can lead to lost updates (last-write-wins). Trigger execution failures are not retried, causing permanent failures on transient errors. Soft-delete restore operation does not cascade to child tasks, leading to data inconsistency.
|
||||
|
||||
## What Changes
|
||||
- Implement optimistic locking using version field for task updates
|
||||
- Add retry mechanism with exponential backoff for trigger execution
|
||||
- Implement cascade restore for soft-deleted tasks and their children
|
||||
|
||||
## Impact
|
||||
- Affected specs: task-management, automation
|
||||
- Affected code:
|
||||
- `backend/app/models/task.py` - Add version field
|
||||
- `backend/app/api/tasks/router.py` - Optimistic locking logic
|
||||
- `backend/app/services/trigger_scheduler.py` - Retry mechanism
|
||||
- `backend/app/api/tasks/router.py` - Cascade restore
|
||||
@@ -0,0 +1,21 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Trigger Execution Retry
|
||||
The system SHALL retry failed trigger executions with exponential backoff to handle transient failures.
|
||||
|
||||
#### Scenario: Trigger succeeds after retry
|
||||
- **WHEN** trigger execution fails due to transient error
|
||||
- **THEN** system retries after 1 second delay
|
||||
- **WHEN** retry succeeds
|
||||
- **THEN** trigger is marked as successful in execution log
|
||||
|
||||
#### Scenario: Trigger exhausts retries
|
||||
- **WHEN** trigger execution fails 3 consecutive times
|
||||
- **THEN** system marks trigger execution as permanently failed
|
||||
- **THEN** system sends alert notification to system administrators
|
||||
- **THEN** execution log contains all retry attempts with error details
|
||||
|
||||
#### Scenario: Non-retryable error
|
||||
- **WHEN** trigger fails with validation or permission error (4xx)
|
||||
- **THEN** system does not retry and marks as failed immediately
|
||||
- **THEN** error is logged with appropriate categorization
|
||||
@@ -0,0 +1,30 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Optimistic Locking for Task Updates
|
||||
The system SHALL use optimistic locking to prevent concurrent update conflicts on tasks.
|
||||
|
||||
#### Scenario: Concurrent update detected
|
||||
- **WHEN** user A and user B both load task at version 1
|
||||
- **WHEN** user A saves changes, incrementing version to 2
|
||||
- **WHEN** user B attempts to save with version 1
|
||||
- **THEN** system returns 409 Conflict error
|
||||
- **THEN** error message instructs user to refresh and retry
|
||||
|
||||
#### Scenario: Sequential updates succeed
|
||||
- **WHEN** user loads task at version N
|
||||
- **WHEN** user saves changes with correct version N
|
||||
- **THEN** system accepts update and increments version to N+1
|
||||
|
||||
### Requirement: Soft Delete Cascade Restore
|
||||
The system SHALL restore child tasks when parent task is restored from soft delete.
|
||||
|
||||
#### Scenario: Parent task restored with children
|
||||
- **WHEN** soft-deleted parent task is restored
|
||||
- **THEN** system identifies child tasks deleted at same timestamp
|
||||
- **THEN** system recursively restores all matching child tasks
|
||||
- **THEN** audit log records restoration of parent and children
|
||||
|
||||
#### Scenario: Selective restore without children
|
||||
- **WHEN** user explicitly requests restore without cascade
|
||||
- **THEN** only parent task is restored
|
||||
- **THEN** child tasks remain in deleted state
|
||||
@@ -0,0 +1,29 @@
|
||||
# Tasks: Add Concurrency Handling and Reliability Improvements
|
||||
|
||||
## 1. Optimistic Locking
|
||||
- [x] 1.1 Add `version` integer field to Task model with default=1
|
||||
- [x] 1.2 Create database migration for version field
|
||||
- [x] 1.3 Include version in TaskResponse schema
|
||||
- [x] 1.4 Modify update_task to accept and validate version
|
||||
- [x] 1.5 Return 409 Conflict when version mismatch detected
|
||||
- [x] 1.6 Auto-increment version on successful update
|
||||
- [x] 1.7 Update frontend to send version with update requests
|
||||
- [x] 1.8 Handle 409 Conflict in frontend with user notification
|
||||
|
||||
## 2. Trigger Retry Mechanism
|
||||
- [x] 2.1 Add retry configuration (max_retries=3, base_delay=1s)
|
||||
- [x] 2.2 Implement exponential backoff (1s, 2s, 4s)
|
||||
- [x] 2.3 Log each retry attempt with attempt number
|
||||
- [x] 2.4 Mark trigger as permanently failed after max retries
|
||||
- [x] 2.5 Send alert notification when trigger exhausts retries
|
||||
|
||||
## 3. Soft Delete Cascade Restore
|
||||
- [x] 3.1 Modify restore_task to find all child tasks deleted at same time
|
||||
- [x] 3.2 Recursively restore child tasks with matching deleted_at timestamp
|
||||
- [x] 3.3 Add option to restore only parent vs cascade restore
|
||||
- [x] 3.4 Log restore operations in audit trail
|
||||
|
||||
## 4. Testing
|
||||
- [x] 4.1 Test concurrent updates with version conflict
|
||||
- [x] 4.2 Test trigger retry on transient failure
|
||||
- [x] 4.3 Test cascade restore of parent with children
|
||||
Reference in New Issue
Block a user