QuickNovel / Contributor proposal REPORT
Read-only evidence snapshot

Start small: make manual backup trustworthy.

Unofficial contributor analysis of seven related backup issues, centered on whether a focused fix for #400 would be welcome.

249open issues at capture
7open pull requests
7backup-core issues
0known backup PR collisions
01

Why this lane is ready for discussion

The detailed audit stays separate. These are the four findings that govern the proposed order.

B-01

Large backups still allocate the complete JSON string

The current serialization mechanism matches the OOM trace in issue #400.

B-02

Changing the download path does not change backup output

The backup path ignores that preference, confirming the basis of #302 and the failed workaround in #463.

B-03

“Successfully stored” is not a verified outcome

The code returns no URI, name, size, or destination and can suppress write errors.

B-04

Restore can report success without restoring

A null input stream exits without throwing; device-bound paths are also merged without revalidation.

02

Related backup issues

These links provide context; they are not proposed closures or bulk dispositions. Confidence describes the assessment evidence, not proof that behavior was reproduced.

No issues match this view.
03

Possible follow-up order

Only the first step is the initial public ask. Later steps remain separate contributions pending maintainer direction and new collision checks.

  1. 01

    Lower-peak streaming export

    Stream JSON without materializing the complete serialized string, surface write failures, and add a large-data regression test.

    Initial proposal for #400
  2. 02

    Explicit manual destination

    Use Android Create Document, propose a real .json filename, and return the created URI.

    Addresses #281, #302, and #463
  3. 03

    Truthful, validate-first restore

    Reject empty or incompatible input before mutation and preserve the current device’s storage destination.

    Foundation for reproducing #319
  4. 04

    Reproduce and reconcile #319

    Test clean and populated storage, missing EPUBs, duplicate names, changed destinations, and revoked grants.

    Keep mechanism claims provisional until reproduced
  5. 05

    Automatic backup discovery

    Only afterwards, decide cadence, persisted folder, retention, and notifications.

    Treat #392 as a duplicate candidate of #183
04

Fit with current upstream work

Open PR #489 already proposes deliberately minimal issue and pull-request templates in response to #210. This pilot does not replace, extend, or compete with that work.

There are no open backup or restore pull requests in the captured seven-PR set. Any implementation would recheck that immediately before work begins.

05

One small question

The existing #400 thread is the natural decision record. This page does not collect or persist approvals.

  1. Q1

    Would a small PR that replaces #400’s complete serialized-string allocation, makes write failures observable, and adds a large-data regression test be welcome?

A brief correction or direction in the existing issue is enough; no formal response template is needed.