Repository navigation
Release 1.31.0 - #221
Release 1.31.0#221
Conversation
Feature/migrate sdk
add release automation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 10ef4d49d2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| recoveryKey = identity == null ? null : RecoveryKeys.forDocumentUri(identity); | ||
| editorGeneration = 0; |
There was a problem hiding this comment.
After a document reaches generation N, opening another document resets editorGeneration to zero here while the same RecoveryWriter retains newestGeneration == N. Consequently, writeIfCurrent rejects the first N-1 snapshots for the new document as stale, so a crash after editing a second file can lose all of those edits; use an activity-wide monotonic generation or reset the writer's generation state when switching documents.
Useful? React with 👍 / 👎.
| } | ||
| discardLoader.run(); | ||
| }) | ||
| .setOnCancelListener(dialog -> { }) |
There was a problem hiding this comment.
When this dialog is shown after activity recreation, restoreState has already restored changed=true, but the editor remains blank until the user chooses Restore or Discard. Pressing Back cancels the dialog through this no-op listener; if the activity is subsequently paused, flushRecoverySnapshot() writes that blank editor under the same recovery key and destroys the recoverable text. Make the dialog non-cancelable or restore/load a safe state when cancellation occurs.
Useful? React with 👍 / 👎.
| File[] files = directory.listFiles(); | ||
| if (files == null) { | ||
| return; | ||
| } | ||
| for (File file : files) { |
There was a problem hiding this comment.
If the process dies after AtomicFile.startWrite() has preserved the last valid base as .bak but before finishWrite(), both the partial base and valid backup exist. This cleanup path deletes the backup and retains the partial file, after which load() reads the base directly and rejects the recovery pair. Handle .bak by restoring it, or read through AtomicFile.openRead(), so an interrupted snapshot does not erase the previous valid draft.
Useful? React with 👍 / 👎.
| writeAtomic(draftFile(metadata.recoveryKey), content); | ||
| writeAtomic(metadataFile(metadata.recoveryKey), published.toJson().toString().getBytes(StandardCharsets.UTF_8)); |
There was a problem hiding this comment.
If the app is killed after the draft write finishes but before the metadata write finishes, the new .draft is paired with the previous .json; load() then rejects it because the size or hash differs, and the prior draft backup has already been removed by the first finishWrite(). Per-file atomic writes therefore do not preserve the last valid recovery generation across this crash window; store the pair together or retain/version the old pair until both new files are published.
Useful? React with 👍 / 👎.
Release checklist