[High] Stop silently losing all chats when the saved store exceeds the localStorage quota
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- javascript
- Área
- backend
Línea de trabajo
Start in index.html at saveStore, createAttachment, attachTranscriptToChat, checkQuota, and promptSetPin; trace how attachment data is saved and how PIN encryption writes are ordered. Then inspect the existing encrypted AttachmentStore and the status line/live region. Done when save failures are visible, large attachments respect the localStorage budget, and enabling a PIN preserves the plaintext store until the encrypted write succeeds.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Priority: High. Type: Bug.
When the saved chat store no longer fits in localStorage, every later save fails silently and all chats, messages, and attachments created from that point are gone on the next reload. With PIN protection, turning the PIN on can lose all existing chats immediately.
Every attachment's full extracted text is stored inside chat.attachments as derivedText, plus a second copy as parents and a third as overlapping children segments (createAttachment and attachTranscriptToChat in index.html). All of it goes into the JSON that saveStore writes to localStorage. The only size check, checkQuota, compares the file against navigator.storage.estimate() and a 50 MB cap, which describe the IndexedDB quota, not the roughly 5 MB localStorage limit. A multi-megabyte text file, a long PDF, or a long transcript makes localStorage.setItem throw. saveStore catches the error and only writes to console.error. The app reports the file as attached and the person keeps chatting.
In promptSetPin, localStorage.removeItem(STORE_KEY) runs before the asynchronous encrypted saveStore. If the larger base64 encrypted blob fails to write, the plaintext copy is already deleted and the encrypted copy never lands.
Suggested fix:
- Show a visible, persistent error in the status line and live region whenever
saveStorefails, and keep showing it on every later failure. - Move
derivedText,parents,segments, and the BM25 index out of thelocalStoragestore into the existing encrypted IndexedDBAttachmentStore, keeping only metadata inchat.attachments. - In
promptSetPin, write the encrypted blob first and removeSTORE_KEYonly after the write succeeds. Use the same order when re-wrapping the data key. - Check the size against a conservative
localStoragebudget before attaching and refuse with a clear message when it would not fit.
Source: index.html, saveStore, createAttachment, attachTranscriptToChat, checkQuota, and promptSetPin.
Verification: Source-level trace only. No browser was available in the review environment.
Generated by Claude Code
- Lenguaje dominante
- HTML
- Estrellas
- 1
- Forks
- 0
- Merge medio
- 5 h 16 min
- PR fusionados (30 d)
- 10
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de DepressionCenter/FieldStationAI
-
[Medium-high] Do not apply formula-injection quoting to spreadsheet data handed to the Python workerAbiertobug help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
DepressionCenter/FieldStationAI#41 ·
Los mantenedores suelen responder en 1 día
-
bug help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
DepressionCenter/FieldStationAI#40 ·
Los mantenedores suelen responder en 1 día
-
enhancement good first issue help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 87/100
DepressionCenter/FieldStationAI#32 ·
Los mantenedores suelen responder en 1 día
-
documentation good first issue help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
DepressionCenter/FieldStationAI#31 ·
Los mantenedores suelen responder en 1 día
-
bug good first issue help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
DepressionCenter/FieldStationAI#29 ·
Los mantenedores suelen responder en 1 día
Todos los issues de DepressionCenter/FieldStationAI
Issues similares
-
ai-driven-fuzzing bug claude Minor
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
linagora/cozy-client#1769 ·
Los mantenedores suelen responder en 1 día
-
[BUG] micronaut-serde-oracle-jdbc-json brings a second OJDBC driver onto the runtime classpathPosiblemente ocupada @ZARAYACH la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
micronaut-projects/micronaut-serialization#1494 · 4 comentarios ·
Los mantenedores suelen responder en 2 días
-
Admin member of a research group cannot see the HX2 allocation until they've been added to itAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
bug
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
Los mantenedores suelen responder en 2 días