[1.1.10][Windows] CLI-session visibility migration deletes workspace link and cannot re-import it
- Langage dominant
- Aucune donnée de langage
- Étoiles
- 2.1k
- Forks
- 153
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
### Short summary
Updating to 1.1.10 silently removed an existing CLI-backed workspace when the new Show Copilot CLI Session setting defaulted to Off. The transcript survived, but the workspace link and 101 activity records were deleted; selecting 90 days did not restore it.
### Affected version or release
GitHub Copilot App 1.1.10 (database schema user_version 79 -> 91)
### Installation context
Windows 11 Enterprise 24H2, build 26100; local in-place repository workspace; CLI-created session imported into Copilot App before the update.
### What happened?
I had a long-running CLI-backed session that was visible and usable in Copilot App before the update. It contained approximately 88 MB / 21,574 events and had current activity well within 90 days.
At app launch, logs show:
```text
Applying deferred update on app launch version=1.1.10
Created pre-update database backup ... target_version="1.1.10"
list_workspaces {"cli_max_age_days":0}
```
A read-only comparison of the automatic pre-update backup with the migrated database showed:
| Table | Before | After migration |
|---|---:|---:|
| `sessions` | 2 | 2 |
| `workspaces` | 2 | 1 |
| `workspace_checkout_bindings` | 2 | 1 |
| `activity_items` | 107 | 8 |
The missing workspace was the CLI-backed session. Its `sessions` row and on-disk `events.jsonl` remained intact, but its `workspaces` row, checkout binding, and 101 associated activity rows were gone (consistent with FK cascade behavior). The UI presented this as complete session loss: it disappeared from both sidebar and search. It could still be resumed only by knowing its UUID and running `copilot --resume=`.
Changing **Settings -> Sessions -> Show Copilot CLI Session** to 90 days sent:
```text
list_workspaces {"cli_max_age_days":0}
list_workspaces {"cli_max_age_days":90}
```
The setting persisted as 90, but the orphaned session was not re-imported and remained absent.
To confirm the behavior, I restored only the deleted workspace/binding/activity rows from the automatic backup while retaining schema 91. The session became usable in the app immediately. Opening/changing the setting caused the app to send `0` first and delete those restored rows again; the subsequent `90` request still did not recreate them. A second manual restore under the persisted 90-day setting was required.
### Steps to reproduce
1. On a version before 1.1.10, have a CLI-created session imported into Copilot App and linked to an in-place repository workspace.
2. Update to 1.1.10.
3. Let the new CLI-session visibility setting use its default Off value.
4. Observe that the session disappears from sidebar and search.
5. Change the setting to 90 days while the session's last activity is within 90 days.
6. Observe that it remains missing.
7. Compare the pre-update backup with the current database: the CLI session row remains, but its workspace, checkout binding, and activity rows have been deleted.
### Expected behavior
1. A visibility preference must hide records, not delete workspace links or activity data.
2. Upgrading must preserve sessions that were already visible before the setting existed, or explicitly prompt before hiding them.
3. Selecting 90 days must re-import any qualifying session even if its `sessions` row exists but its workspace link is missing.
4. A settings control must not transiently reconcile at `0` before applying the selected value.
5. Reconciliation should repair orphaned CLI sessions rather than silently skip them.
6. The app should expose a recovery action instead of making a large session appear destroyed.
### Additional context
No private transcript or repository data is attached. The automatic pre-update database backup and sanitized logs are preserved and can be provided privately. `PRAGMA integrity_check` passes; this is referential/reconciliation behavior, not SQLite corruption.
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
Commencez par suivre la migration 1.1.10 et les appels de réconciliation de list_workspaces, en particulier la transition du paramètre cli_max_age_days=0 à 90. Comparez workspace, workspace_checkout_bindings et activity_items avec la sauvegarde automatique précédant la mise à jour, tout en conservant la ligne sessions. Le travail est terminé lorsque les changements de visibilité ne suppriment plus les liens ni les données d’activité, et qu’une session CLI orpheline répondant aux critères peut être restaurée lorsque 90 jours est sélectionné.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- sqlite
- Domaine
- cli, database, desktop
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- Active
- Clarté
- Plutôt claire
- Accessibilité débutants
- 45/100