Repository navigation
fix(upload): preserve SHA-1 integrity during large-file resume - #365
Conversation
Quality Keeper — Advisory ReviewSource:
Quality Keeper assessed the repository, executed checks, and collected results, covering 19 quality expectations. Five repository-quality areasHard expectations keep their exact Evidence State. Advisory applicability questions are separate. Implementation or suite presence is not proof of a trusted run.
Observability — 0 hard, 0 advisoryCan operators understand and diagnose repository-owned runtime behavior? Hard expectations None selected. Applicability Review Gaps (advisory) None. Product Analytics — 0 hard, 0 advisoryDoes repository-owned product analytics instrumentation behave safely and as declared? Hard expectations None selected. Applicability Review Gaps (advisory) None. User Feedback — 0 hard, 0 advisoryDo repository-owned feedback and support-intake flows behave safely and accessibly? Hard expectations None selected. Applicability Review Gaps (advisory) None. Reliability — 3 hard, 0 advisoryDoes repository-owned software fail, recover, time out, and report health predictably? Hard expectations
Applicability Review Gaps (advisory) None. Security — 4 hard, 0 advisoryDo static controls and repository-owned security behaviors protect the intended boundaries? Hard expectations
Applicability Review Gaps (advisory) None. Other registered quality — 12 hard, 0 advisoryRegistered Testing Types not assigned to one of the five focused areas. Hard expectations
Applicability Review Gaps (advisory) None. Result
CoveredQuality Keeper found acceptable evidence for one or more expectations in these Testing Types.
Needs attentionQuality Keeper does not yet have acceptable evidence for these Testing Types. Some have partial checks that need to run, be fixed, or be connected. Others need new proof or seeded tests. In both cases, Quality Keeper cannot count them as covered yet.
Quality Keeper changes no Evidence State. Pending, missing, executed-but-not-exercised, and review items are not passing, and seeded scaffolds are next actions, not evidence, until applied and re-evaluated. Full breakdown (19 expectations)
New to these terms? Start with the Quality Keeper Standards Wiki to learn what each testing type means, why it applies, and what counts as evidence. |
* fix(upload): record large-file SHA-1 and support resume (#354) * fix(upload): retry upload POST connection failures by default (#344) * fix(upload): preserve SHA-1 integrity during large-file resume (#365) * chore: update vulnerable transitive dependencies (#340) * chore: update development tooling for dependency audit (#361) * chore: allowlist minimatch audit advisory (#363) * chore(release): prepare isolated v0.5.0 * test(upload): verify connection-failure phases and SHA-1 * docs: make the upload retry migration example self-contained * fix(client): redact credentials from SDK object diagnostics (#351) (#375) * test: cover credential redaction in SDK object diagnostics Assert that util.inspect, console.log, JSON.stringify and object spread of clients, bucket and file handles, auth stores and upload URL pools never contain the application key or authorization tokens, and that getAuth(), authorize() and file auth caches still carry the real token. * fix(client): redact credentials from SDK object diagnostics Hold the application key, stored authorization and upload URL pools in private fields, give B2Client and the account-info stores a redacted toJSON/inspect summary, and expose accountInfo through a getter, mirroring the Partner client. * docs: note credential redaction and the accountInfo accessor change * feat(upload): add single-file connection-fault retry opt-out (#376) * feat(upload): add single-file connection-fault retry opt-out * refactor(upload): resolve connection-fault retry options --------- Co-authored-by: Sophie <49928680+sophiecarreras@users.noreply.github.com>
Context
Resuming different same-size content could reuse an unfinished large file with an older
large_file_sha1, then finish the new bytes under the stale checksum. Whole-file prehash reads also continued after cancellation.Root cause
Resume criteria were copied before the computed digest was added, and matching discarded both computed and caller-provided digests. The prehash loop neither checked cancellation between slices nor forwarded the signal to reads.
Changes
file-info-mismatch.Verification
Tests were added before production changes. The regression selection failed on the original code:
Each break was then applied alone and reverted:
rejects ... resume with a different ... computed ... whole-file SHA-1(automatic and explicit)compares whole-file SHA-1 metadataand caller-supplied resume casespasses the signal to a pending whole-file prehash readRestored implementation:
pnpm verify: passed, including lint, documentation/spelling checks, typechecks, 192 SDK harness tests, 2,584 unit tests (9 skipped), build, and metadata/export checks.pnpm test:coverage: passed, 2,617 tests (9 skipped); unchanged gates passed with 97.20% statements, 92.61% branches, 98.17% functions, and 98.67% lines.git diff --check: passed.Closes #364