mirror of
https://github.com/CherryHQ/cherry-studio.git
synced 2025-12-24 10:40:07 +08:00
chore: remove docs
This commit is contained in:
suyao
parent
7fdae0173c
commit
18da9a19fd
@ -1,145 +0,0 @@
|
||||
# V2 Database Service Integration Status
|
||||
|
||||
## Overview
|
||||
The unified database service (DbService) has been successfully integrated into messageThunk.ts with feature flag support. This allows gradual rollout and easy rollback if issues occur.
|
||||
|
||||
## Feature Flag Control
|
||||
```javascript
|
||||
// Enable V2 implementation
|
||||
VITE_USE_UNIFIED_DB_SERVICE=true yarn dev
|
||||
|
||||
// Or via browser console
|
||||
localStorage.setItem('featureFlags', JSON.stringify({ USE_UNIFIED_DB_SERVICE: true }))
|
||||
location.reload()
|
||||
```
|
||||
|
||||
## Integration Status
|
||||
|
||||
### ✅ Completed Integrations
|
||||
|
||||
#### Phase 2.1 - Read Operations (STABLE - Tested by user)
|
||||
- **loadTopicMessagesThunk** → `loadTopicMessagesThunkV2`
|
||||
- Location: messageThunk.ts:843
|
||||
- Status: ✅ STABLE (confirmed by user)
|
||||
- Handles both regular topics and agent sessions
|
||||
|
||||
#### Phase 2.2 - Helper Functions
|
||||
- **updateFileCount** → `updateFileCountV2`
|
||||
- Location: messageThunk.ts:1596
|
||||
- Status: ✅ Integrated
|
||||
- Used in cloneMessagesToNewTopicThunk
|
||||
|
||||
#### Phase 2.3 - Delete Operations
|
||||
- **deleteSingleMessageThunk** → `deleteMessageFromDBV2`
|
||||
- Location: messageThunk.ts:931
|
||||
- Status: ✅ Integrated
|
||||
|
||||
- **deleteMessageGroupThunk** → `deleteMessagesFromDBV2`
|
||||
- Location: messageThunk.ts:988
|
||||
- Status: ✅ Integrated
|
||||
|
||||
- **clearTopicMessagesThunk** → `clearMessagesFromDBV2`
|
||||
- Location: messageThunk.ts:1039
|
||||
- Status: ✅ Integrated
|
||||
|
||||
#### Phase 2.4 - Write Operations
|
||||
- **saveMessageAndBlocksToDB** → `saveMessageAndBlocksToDBV2`
|
||||
- Location: messageThunk.ts:209
|
||||
- Status: ✅ Integrated
|
||||
- Used in sendMessage, branches, and resends
|
||||
|
||||
#### Phase 2.5 - Update Operations
|
||||
- **updateSingleBlock** → `updateSingleBlockV2`
|
||||
- Location: messageThunk.ts:326, 1351
|
||||
- Status: ✅ Integrated
|
||||
- Used in throttled block updates and translation updates
|
||||
|
||||
- **bulkAddBlocks** → `bulkAddBlocksV2`
|
||||
- Location: messageThunk.ts:1587
|
||||
- Status: ✅ Integrated
|
||||
- Used in cloneMessagesToNewTopicThunk
|
||||
|
||||
- **updateBlocks (bulkPut)** → `updateBlocksV2`
|
||||
- Location: messageThunk.ts:221, 259, 1684
|
||||
- Status: ✅ Integrated
|
||||
- Used in saveMessageAndBlocksToDB, updateExistingMessageAndBlocksInDB, updateMessageAndBlocksThunk
|
||||
|
||||
- **updateMessage** → `updateMessageV2`
|
||||
- Location: messageThunk.ts:1669
|
||||
- Status: ✅ Integrated
|
||||
- Used in updateMessageAndBlocksThunk
|
||||
|
||||
## Not Yet Integrated
|
||||
|
||||
### Functions Available but Not Used
|
||||
These V2 functions exist but haven't been integrated yet as their usage patterns are different:
|
||||
|
||||
- **getRawTopicV2** - Available but not directly replacing db.topics.get() calls
|
||||
- **getTopicV2** - Available but not directly replacing db.topics.get() calls
|
||||
- **persistExchangeV2** - Available for future use with message exchanges
|
||||
|
||||
### Complex Operations Still Using Original Implementation
|
||||
These operations involve complex transactions and topic management that would need careful refactoring:
|
||||
|
||||
1. **Topic message list updates** (db.topics.update with messages array)
|
||||
- Used after delete operations
|
||||
- Used in resendMessageThunk
|
||||
- Used in regenerateAssistantMessageThunk
|
||||
|
||||
2. **Transaction-based operations**
|
||||
- cloneMessagesToNewTopicThunk (partial integration)
|
||||
- initiateTranslationThunk
|
||||
- removeBlocksThunk
|
||||
|
||||
## Testing Checklist
|
||||
|
||||
### High Priority (Core Operations)
|
||||
- [x] Load messages for regular topic
|
||||
- [x] Load messages for agent session
|
||||
- [ ] Send message in regular chat
|
||||
- [ ] Send message in agent session
|
||||
- [ ] Delete single message
|
||||
- [ ] Delete message group
|
||||
- [ ] Clear all messages
|
||||
|
||||
### Medium Priority (Edit Operations)
|
||||
- [ ] Update message content
|
||||
- [ ] Update message blocks
|
||||
- [ ] Update translation blocks
|
||||
- [ ] File reference counting
|
||||
|
||||
### Low Priority (Advanced Features)
|
||||
- [ ] Clone messages to new topic
|
||||
- [ ] Resend messages
|
||||
- [ ] Regenerate assistant messages
|
||||
- [ ] Multi-model responses
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. **Test Current Integrations**
|
||||
- Enable feature flag and test all integrated operations
|
||||
- Monitor for any errors or performance issues
|
||||
- Verify data consistency
|
||||
|
||||
2. **Phase 3 Consideration**
|
||||
- Consider refactoring complex topic update operations
|
||||
- Evaluate if persistExchangeV2 should be used for user+assistant pairs
|
||||
- Plan migration of remaining db.topics operations
|
||||
|
||||
3. **Performance Monitoring**
|
||||
- Compare load times between original and V2
|
||||
- Check memory usage with large message histories
|
||||
- Verify agent session performance
|
||||
|
||||
## Rollback Instructions
|
||||
If issues occur, disable the feature flag immediately:
|
||||
```javascript
|
||||
localStorage.setItem('featureFlags', JSON.stringify({ USE_UNIFIED_DB_SERVICE: false }))
|
||||
location.reload()
|
||||
```
|
||||
|
||||
## Notes
|
||||
- All V2 implementations maintain backward compatibility
|
||||
- Agent session operations (IPC-based) are handled transparently
|
||||
- File operations only apply to Dexie storage, not agent sessions
|
||||
- Feature flag allows gradual rollout and A/B testing
|
||||
@ -1,206 +0,0 @@
|
||||
# Rollback Strategy for Unified Database Service Migration
|
||||
|
||||
## Overview
|
||||
This document outlines the rollback procedures for the unified database service migration. The migration uses feature flags to enable gradual rollout and quick rollback capabilities.
|
||||
|
||||
## Quick Rollback (< 1 minute)
|
||||
|
||||
### Via Browser Console
|
||||
```javascript
|
||||
// Disable the unified DB service immediately
|
||||
localStorage.setItem('featureFlags', JSON.stringify({ USE_UNIFIED_DB_SERVICE: false }))
|
||||
location.reload()
|
||||
```
|
||||
|
||||
### Via Code (Emergency)
|
||||
```typescript
|
||||
// In src/renderer/src/config/featureFlags.ts
|
||||
export const featureFlags: FeatureFlags = {
|
||||
USE_UNIFIED_DB_SERVICE: false // Change from true to false
|
||||
}
|
||||
```
|
||||
|
||||
## Rollback Triggers
|
||||
|
||||
Monitor these indicators to determine if rollback is needed:
|
||||
|
||||
### Critical Issues (Immediate Rollback)
|
||||
- [ ] Data loss or corruption
|
||||
- [ ] Application crashes on startup
|
||||
- [ ] Complete failure to load messages
|
||||
- [ ] Agent sessions completely broken
|
||||
- [ ] Performance degradation > 50%
|
||||
|
||||
### Major Issues (Rollback within 1 hour)
|
||||
- [ ] Intermittent message loading failures (> 10% error rate)
|
||||
- [ ] Memory leaks detected
|
||||
- [ ] Performance degradation 20-50%
|
||||
- [ ] File upload/attachment issues
|
||||
- [ ] Message editing/deletion not working
|
||||
|
||||
### Minor Issues (Consider Rollback)
|
||||
- [ ] Performance degradation < 20%
|
||||
- [ ] UI glitches or inconsistencies
|
||||
- [ ] Non-critical features affected
|
||||
- [ ] Increased error logs but functionality intact
|
||||
|
||||
## Rollback Procedures
|
||||
|
||||
### Level 1: Feature Flag Toggle (Immediate)
|
||||
**When:** Any critical issue detected
|
||||
**Time:** < 1 minute
|
||||
**Data Impact:** None
|
||||
|
||||
1. Set feature flag to false:
|
||||
```javascript
|
||||
localStorage.setItem('featureFlags', JSON.stringify({ USE_UNIFIED_DB_SERVICE: false }))
|
||||
```
|
||||
2. Reload application
|
||||
3. Verify original functionality restored
|
||||
4. Alert team about rollback
|
||||
|
||||
### Level 2: Code Revert (Quick)
|
||||
**When:** Feature flag not sufficient or broken
|
||||
**Time:** < 5 minutes
|
||||
**Data Impact:** None
|
||||
|
||||
1. Revert to previous commit:
|
||||
```bash
|
||||
git revert HEAD # If just deployed
|
||||
# or
|
||||
git checkout <last-known-good-commit>
|
||||
```
|
||||
2. Rebuild and deploy:
|
||||
```bash
|
||||
yarn build:check
|
||||
yarn build
|
||||
```
|
||||
3. Test core functionality
|
||||
4. Document issue for investigation
|
||||
|
||||
### Level 3: Full Rollback (Planned)
|
||||
**When:** Systemic issues discovered
|
||||
**Time:** 30 minutes
|
||||
**Data Impact:** Potential data migration needed
|
||||
|
||||
1. Notify all stakeholders
|
||||
2. Export any critical data if needed
|
||||
3. Restore from backup branch:
|
||||
```bash
|
||||
git checkout main
|
||||
git branch -D feature/unified-db-service
|
||||
git push origin --delete feature/unified-db-service
|
||||
```
|
||||
4. Clean up any migration artifacts:
|
||||
- Remove `messageThunk.v2.ts`
|
||||
- Remove `src/renderer/src/services/db/` if created
|
||||
- Remove feature flags configuration
|
||||
5. Run full test suite
|
||||
6. Deploy clean version
|
||||
|
||||
## Pre-Rollback Checklist
|
||||
|
||||
Before initiating rollback:
|
||||
|
||||
1. **Capture Current State**
|
||||
- [ ] Export performance metrics
|
||||
- [ ] Save error logs
|
||||
- [ ] Document specific failure scenarios
|
||||
- [ ] Note affected user percentage
|
||||
|
||||
2. **Preserve Evidence**
|
||||
- [ ] Take screenshots of errors
|
||||
- [ ] Export browser console logs
|
||||
- [ ] Save network traces if relevant
|
||||
- [ ] Backup current localStorage
|
||||
|
||||
3. **Communication**
|
||||
- [ ] Notify development team
|
||||
- [ ] Update status page if applicable
|
||||
- [ ] Prepare user communication if needed
|
||||
|
||||
## Post-Rollback Actions
|
||||
|
||||
After successful rollback:
|
||||
|
||||
1. **Verification**
|
||||
- [ ] Test message loading (regular chat)
|
||||
- [ ] Test agent sessions
|
||||
- [ ] Verify file attachments work
|
||||
- [ ] Check message editing/deletion
|
||||
- [ ] Confirm no data loss
|
||||
|
||||
2. **Investigation**
|
||||
- [ ] Analyze performance metrics
|
||||
- [ ] Review error logs
|
||||
- [ ] Identify root cause
|
||||
- [ ] Create bug report
|
||||
|
||||
3. **Planning**
|
||||
- [ ] Document lessons learned
|
||||
- [ ] Update rollback procedures if needed
|
||||
- [ ] Plan fixes for identified issues
|
||||
- [ ] Schedule retry with fixes
|
||||
|
||||
## Monitoring Commands
|
||||
|
||||
### Check Feature Flag Status
|
||||
```javascript
|
||||
// In browser console
|
||||
JSON.parse(localStorage.getItem('featureFlags') || '{}')
|
||||
```
|
||||
|
||||
### View Performance Metrics
|
||||
```javascript
|
||||
// In browser console (if performance monitor is exposed)
|
||||
performanceMonitor.getAllComparisons()
|
||||
```
|
||||
|
||||
### Check Error Rate
|
||||
```javascript
|
||||
// Check application logs
|
||||
loggerService.getLogs().filter(log => log.level === 'error' && log.context.includes('DbService'))
|
||||
```
|
||||
|
||||
## Recovery Validation
|
||||
|
||||
After rollback, validate system health:
|
||||
|
||||
1. **Functional Tests**
|
||||
```bash
|
||||
yarn test
|
||||
yarn test:e2e # If available
|
||||
```
|
||||
|
||||
2. **Manual Validation**
|
||||
- Create new chat conversation
|
||||
- Send messages with attachments
|
||||
- Edit existing messages
|
||||
- Delete messages
|
||||
- Start agent session
|
||||
- Load historical messages
|
||||
|
||||
3. **Performance Check**
|
||||
- Message load time < 500ms
|
||||
- No memory leaks after 10 minutes
|
||||
- CPU usage normal
|
||||
- Network requests successful
|
||||
|
||||
## Emergency Contacts
|
||||
|
||||
- **Tech Lead:** [Contact Info]
|
||||
- **DevOps:** [Contact Info]
|
||||
- **Product Owner:** [Contact Info]
|
||||
|
||||
## Rollback History
|
||||
|
||||
| Date | Version | Issue | Rollback Type | Resolution |
|
||||
|------|---------|-------|---------------|------------|
|
||||
| - | - | - | - | - |
|
||||
|
||||
## Notes
|
||||
|
||||
- Always prefer feature flag rollback first (least disruptive)
|
||||
- Document any rollback in the history table above
|
||||
- If multiple rollbacks needed, consider pausing migration
|
||||
- Performance degradation baseline: original implementation metrics
|
||||
Loading…
Reference in New Issue
Block a user