Skip to content

feat(deletion): execute graceful and forced lock deletion - #21

Open
dzdidi wants to merge 1 commit into
stack/graceful-deletion/04-access-drainfrom
stack/graceful-deletion/05-execution
Open

feat(deletion): execute graceful and forced lock deletion#21
dzdidi wants to merge 1 commit into
stack/graceful-deletion/04-access-drainfrom
stack/graceful-deletion/05-execution

Conversation

@dzdidi

@dzdidi dzdidi commented Aug 18, 2026

Copy link
Copy Markdown
Collaborator

Summary

Part 5 of the graceful-deletion stack. Depends on Part 4.

Completes the durable graceful and active-force deletion lifecycle.

Graceful execution:

  1. publishes and verifies the public tombstone;
  2. starts and drains frozen payment obligations;
  3. drains existing credentials;
  4. issues final credentials;
  5. drains final reads;
  6. verifies and removes frozen guarded content;
  7. verifies the retained tombstone;
  8. stops before the separately deferred operational-state purge.

The change also:

  • adds exact external-action ownership;
  • uses storage-authoritative time after the relevant fence;
  • executes public-first active-force deletion;
  • persists permanent force receipts;
  • adds operation-specific dependency readiness;
  • supervises deletion and verification workers;
  • adds bounded shutdown and worker-failure handling;
  • covers PostgreSQL crash/reclaim boundaries;
  • removes duplicate executor and test-fixture paths;
  • migrates the Paykit local demo to persisted runtime-master-key schema v2.

Active force is the only intentionally unconditional deletion path.

Graceful Pubky tombstone publication remains a GET followed by unconditional PUT. A replacement observed before the PUT is preserved, but an out-of-band replacement between the final GET and PUT may be overwritten. This accepted Pubky 0.9.3 limitation is explicitly documented.

Contract and risk impact

  • Public API or SDK contract
  • Persisted data or migration
  • Authentication, authorization, identity, or secret handling
  • Payment or entitlement behavior
  • Runtime, deployment, or observability
  • No contract/risk impact

Migration:

  • 0017_content_lock_deletion_resource_replaced.sql

Notable contract and risk changes:

  • graceful deletion now executes through its durable phase machine;
  • force=true executes or escalates active-force deletion;
  • destructive external actions require exact live-claim ownership;
  • dependency readiness recovers only from operation-specific healthy evidence;
  • Compose secrets schema v2 persists locksRuntimeMasterKey;
  • schema v1 local-demo state fails closed and requires the documented destructive reset;
  • PurgeOperationalState remains deferred.

Verification

Run successfully on the exact final artifact:

  • cargo fmt --all -- --check — passed
  • cargo test --workspace --all-targets --all-features — passed
  • cargo clippy --workspace --all-targets --all-features -- -D warnings — passed
  • npm --prefix examples/js-sdk run check — passed
  • npm --prefix examples/js-sdk run smoke:paykit-compose — passed
  • npm --prefix locks-sdk/bindings/js test — passed
  • bash scripts/test-compose-bootstrap.sh — passed
  • git diff --check codex/bitkit-local-e2e-fixes..HEAD — passed

Recorded focused results from the final run:

  • locks-service library: 355 passed
  • deletion integration: 29 passed
  • tombstone integration: 6 passed
  • PostgreSQL E2E: 12 passed
  • JS/WASM generated-package and example smoke checks: passed
  • Paykit Compose model, reader-worker, and bootstrap smoke checks: passed

Exact reviewed artifact:

  • Base: ba2cfc58d1932e7fd38071b9936d53c732f62ed6
  • Tip: c54edaea8dea0b06ae92d9d3216dc42f52e9b91c
  • Tree: 08a4785704a1fb236a31b4cd572afade94956d6a
  • Canonical patch SHA-256: c92dba51e52f0a257266f22dabb258f3a02ffd041039c752b32994da35a0d756

Independent exact-artifact reviews approved:

  • Bitkit and Compose integration;
  • semantic safety of the code reduction;
  • stack topology and preservation.

Documentation

Updated:

  • docs/API.md
  • docs/RUNTIME.md
  • docs/plans/2026-08-10-graceful-content-lock-deletion.md
  • examples/js-sdk/README.md

The documentation covers:

  • graceful and active-force behavior;
  • public failure and lifecycle projection;
  • the accepted Pubky GET-to-PUT overwrite race;
  • worker readiness and supervision;
  • Compose runtime-master-key schema v2;
  • fail-closed handling and destructive reset requirements for schema v1.

Checklist

  • The change is focused and self-reviewed.
  • Regression tests were added where practical.
  • No credentials, identities, private content, payment material, or generated local state are included.
  • Formatting and relevant tests/lints pass.

Run the durable graceful and active-force deletion lifecycle with exact claim fencing, storage-owned time, final-access draining, operation-specific readiness, supervised shutdown, and crash-safe PostgreSQL and memory behavior. Keep the accepted Pubky GET-to-PUT overwrite race explicit, and remove duplicate executor and test-fixture paths.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant