Bug 4: resolveRenewalActivationSubscription - add fallback by user_id+subscribe_id
with SELECT FOR UPDATE when token lookup fails
Bug 5: appleIAPNotifyLogic - return error on product ID mapping failure instead of
silently dropping the notification
Bug 6: NewPurchase fallback query - wrap in transaction with SELECT FOR UPDATE to
prevent concurrent duplicate subscription creation
Bug 7: appleIAPNotifyLogic - fix UserId=0 by reverse-lookup from original purchase
order; create renewal audit order record for DID_RENEW/SUBSCRIBED notifications
Bug 8: UpdateOrderStatus - pre-delete cache before DB write (double-delete) to
close TOCTOU window between DB update and cache invalidation
Bug 9: validateNewUserOnlyEligibilityAtActivation - add Redis distributed lock on
user_id to serialise concurrent new-user-only order activations
Co-authored-by: multica-agent <github@multica.ai>
- Add `activation_context` TEXT column to `order` table (migration 02150)
- purchaseLogic: write TemporaryOrderInfo JSON to order.ActivationContext in the same
insert transaction; Redis write is now best-effort (non-fatal)
- redeemCodeLogic: write redemption {type, redemption_code_id, unit_time, quantity} JSON
to order.ActivationContext at order creation; Redis write is now best-effort (non-fatal)
- getTempOrderInfo: on Redis miss, fall back to order.ActivationContext from DB;
logs CRITICAL and returns error if both are missing (old orders with no DB record)
- RedemptionActivate: on Redis miss, fall back to order.ActivationContext from DB;
same CRITICAL log path for legacy orders
Co-authored-by: multica-agent <github@multica.ai>
- 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
When administrators update subscription plan configurations (traffic limits,
nodes, speed limits, etc.), existing subscribers were not seeing the updated
settings immediately. This was caused by stale cache entries that were not
being invalidated.
The issue occurred because:
- User subscription queries cache the entire result including preloaded plan details
- Plan update/delete operations only cleared the plan's own cache keys
- User subscription cache keys (cache:user:subscribe:user:{userId}) remained stale
This fix ensures that when a subscription plan is updated or deleted, all
associated user subscription caches are properly invalidated by:
- Querying all active users subscribed to the plan
- Building cache keys for each affected user
- Clearing both plan and user subscription caches atomically
Users will now immediately see updated plan configurations without waiting
for cache expiration.
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
- Add optional short_code parameter to DeviceLoginRequest
- Add ShortCode field to Device model
- Save short_code to database during device registration
- Add database migration for user_device.short_code column
- Fix duplicate variable declaration in routes.go
shanshanzhong147
EUForest