- Add subscribe traffic_limit schema and migration\n- Support traffic_limit in admin create/update and list/details\n- Apply traffic_limit when building server user list speed limits\n- Add public user traffic stats API
- Node group CRUD operations with traffic-based filtering
- Three grouping modes: average distribution, subscription-based, and traffic-based
- Automatic and manual group recalculation with history tracking
- Group assignment preview before applying changes
- User subscription group locking to prevent automatic reassignment
- Subscribe-to-group mapping configuration
- Group calculation history and detailed reports
- System configuration for group management (enabled/mode/auto_create)
Database:
- Add node_group table for group definitions
- Add group_history and group_history_detail tables for tracking
- Add node_group_ids (JSON) to nodes and subscribe tables
- Add node_group_id and group_locked fields to user_subscribe table
- Add migration files for schema changes
This commit addresses critical issues in the redemption code activation flow
to ensure data consistency, prevent duplicate redemptions, and improve user
experience.
Key improvements:
1. Transaction Safety (P0)
- Wrap subscription creation, used count update, and record insertion in
a single database transaction
- Ensure atomicity: all operations succeed or all rollback
- Prevent orphaned records and data inconsistencies
2. Idempotency Protection (P0)
- Add redemption record check before processing to prevent duplicate
operations on queue task retries
- Maintain idempotency at multiple layers: interface, order, and record
3. Distributed Lock (P1)
- Implement Redis-based distributed lock (10s timeout) to prevent
concurrent duplicate redemptions
- Lock key format: redemption_lock:{user_id}:{code}
4. IsNew Field Correction (P2)
- Fix IsNew field to correctly determine first-time purchases using
IsUserEligibleForNewOrder method
- Ensure accurate statistics and future commission calculations
5. Quota Pre-check (P2)
- Add quota validation at interface layer for immediate user feedback
- Prevent "processing" status followed by eventual failure
6. Extended Cache TTL (P2)
- Increase Redis cache expiration from 30 minutes to 2 hours
- Ensure queue tasks can retrieve redemption data even with delays
7. Error Handling (P2)
- Clean up Order records when Redis cache or queue enqueue fails
- Prevent orphaned Order records in the database
8. Cache Clearing Optimization
- Add user subscription cache clearing after activation
- Ensure both node-side and user-side display latest subscription info
Technical details:
- Modified: internal/logic/public/redemption/redeemCodeLogic.go
- Modified: queue/logic/order/activateOrderLogic.go
- Modified: internal/model/redemption/default.go (transaction support)
Testing:
- All changes compiled successfully
- Comprehensive flow verification completed
- Ready for production deployment
BREAKING CHANGE: None
- Fix task error handling: return actual errors instead of nil to enable retry
- Add idempotency check: skip processing for already finished orders
- Extend temp order cache: increase from 15 minutes to 24 hours
- Configure retry policy: add MaxRetry(5) for all payment callbacks (Epay, Alipay, Stripe)
This fixes the critical issue where paid orders were being lost due to:
1. Failed tasks being marked as successful and deleted from queue
2. Temporary order info expiring before queue processing
3. No retry mechanism for transient failures
Changes:
- queue/logic/order/activateOrderLogic.go: Fix error returns and add idempotency
- internal/logic/public/portal/purchaseLogic.go: Extend cache to 24 hours
- internal/logic/notify/*NotifyLogic.go: Add retry configuration
- Add quota check in preCreateOrderLogic for order preview
- Move quota check inside transaction in purchaseLogic to prevent race condition
- Add quota check in activateOrderLogic as final safeguard when creating subscription
- Add quota check in redeemCodeLogic when redeeming codes for new subscriptions