Implementing GDPR Article 17 correctly with Promise.allSettled and export batching

The problem with sequential await
Promise.allSettled as the solution
HTTP 207 as the correct status code
The OOM problem during export
Batching as the solution
What these two fixes have in common
All articles in the series

The problem with sequential await

The DELETE /account endpoint deletes all of a user’s data: BullMQ jobs, Qdrant collections, S3 blobs and the Zitadel identity. This is GDPR Article 17, the right to erasure.

The original code looked like this:

// Original: sequential await chain. First failure stops all remaining steps.
router.delete('/', authMiddleware, async (req, res) => {
  const { userId } = req.auth;
  try {
    await deleteUserJobs(userId);
    await deleteUserCollections(userId);
    await deleteUserBlobs(userId);
    await deleteZitadelUser(userId);
    res.status(204).send();
  } catch (err) {
    res.status(500).json({ error: 'Deletion failed' });
  }
});

That looks clean, but it has a structural problem: if deleteUserCollections fails, for example because Qdrant is briefly unreachable, deleteUserBlobs and deleteZitadelUser are never called. The Qdrant data is missing, but S3 blobs and the Zitadel identity remain.

For Article 17, this means a deletion request remains silently incomplete under load or during brief infrastructure failures. The user receives a 500 error, but no information about what was deleted and what was not.

Promise.allSettled as the solution

Promise.allSettled runs all promises in parallel and reports individually whether each promise was fulfilled or rejected. It does not stop when one promise fails.

That is exactly the right tool for this case: all four deletion steps should always run, regardless of what happens to the others.

router.delete('/', authMiddleware, async (req, res) => {
  const { userId } = (req as AuthenticatedRequest).auth;

  const steps = [
    { name: 'bullmq', fn: () => deleteUserJobs(userId) },
    { name: 'qdrant', fn: () => deleteUserCollections(userId) },
    { name: 's3', fn: () => deleteUserBlobs(userId) },
    { name: 'zitadel', fn: () => deleteZitadelUser(userId) },
  ];

  const results = await Promise.allSettled(steps.map((s) => s.fn()));

  const failed = steps
    .map((s, i) => ({ name: s.name, result: results[i] }))
    .filter((s) => s.result.status === 'rejected')
    .map((s) => ({
      store: s.name,
      // Capture rejection reason for logging and response
      reason: s.result.status === 'rejected' ? String(s.result.reason) : '',
    }));

  if (failed.length > 0) {
    logger.error({ userId, failed }, 'Partial account deletion failure');
    // HTTP 207: some steps succeeded, some failed
    return res.status(207).json({
      deleted: steps.length - failed.length,
      failed,
    });
  }

  res.status(204).send();
});

With Promise.allSettled, all four steps always run. If BullMQ or Qdrant is unreachable, S3 and Zitadel still run. This is friendly to idempotent operations: the user can repeat the request, and stores that have already been deleted will simply acknowledge the second attempt without an error.

HTTP 207 as the correct status code

For partial failures, the endpoint returns HTTP 207 rather than 500.

500 would signal: “I do not know what happened.” 207 is the correct code for “Multi-Status”: some operations worked, others did not. The response body lists what failed:

{
  "deleted": 3,
  "failed": [{ "store": "qdrant", "reason": "connect ECONNREFUSED 127.0.0.1:6333" }]
}

The extension and frontend can process this response and show the user a meaningful message instead of leaving them with a generic error.

The OOM problem during export

GET /account/export loads all of a user’s saved screenshots and returns a presigned S3 URL for each one. The original code:

// Original: all presigns generated concurrently. OOM at scale.
const points = await scrollAllPoints(userId);
const records = await Promise.all(points.map((p) => getPresignedUrl(p.payload.image.blobName)));

scrollAllPoints paginates internally in batches of 100, which is correct. The problem is Promise.all(points.map(...)): if a user has 1,000 screenshots, 1,000 S3 presign requests are fired simultaneously. Each presign request holds open HTTP client state in memory.

With a thousand requests, two things happen at once: the heap grows until an OOM kill, and the AWS SDK throws rate-limit errors because too many parallel connections are established.

Batching as the solution

The solution is sequential batch processing with a fixed batch size:

const points = await scrollAllPoints(userId);
const records: ExportRecord[] = [];

// Process presigns in batches of 50 to prevent OOM and S3 rate limits
for (let i = 0; i < points.length; i += 50) {
  const batch = points.slice(i, i + 50);
  const batchRecords = await Promise.all(
    batch.map(async (p) => ({
      capturedAt: p.payload.capturedAt,
      platform: p.payload.platform,
      url: await getPresignedUrl(p.payload.image.blobName),
      tags: p.payload.tags ?? [],
      note: p.payload.note ?? '',
    }))
  );
  records.push(...batchRecords);
}

res.json({ records });

Within each batch, 50 requests run in parallel. Between batches, the heap is freed again. Response time increases with very large numbers of captures: 1,000 captures mean 20 batches of 50, with each batch taking approximately 100ms, or roughly 2 seconds overall. But there is no OOM risk.

The response format does not change. Only the internal processing path is different.

What these two fixes have in common

Both problems come from the same mindset: “Happy path first, failures will not happen.”

For DELETE, the assumption was that all stores are always reachable. For export, the assumption was that users do not have large amounts of data.

Both assumptions hold during development. In production, with real users and real failure rates, they no longer do. Infrastructure is flaky, and users accumulate data.

GDPR Article 17 and Article 20, data portability, require these endpoints to work correctly under real conditions. That was not guaranteed before these fixes.

Left: DELETE uses Promise.allSettled to run all four stores in parallel and returns HTTP 207 for partial failures. Right: export batching processes S3 presigns in groups of 50 instead of all at once.

On the left, the DELETE path shows four parallel deletion operations with Promise.allSettled. Each operation runs independently, and partial failures are documented in the response. On the right, the export path shows the sequential batch loop: 50 presigns at a time, then the next batch, until all points have been processed. The original illustration retains its German labels.

All articles in the series

Vision and system overview: Chrome Extension, RAG architecture and project background: Read article
Building a RAG system: Qdrant, embeddings and cosine similarity in TypeScript: Read article
AI provider abstraction: Ollama vs. OpenAI, interface design and no vendor lock-in: Read article
Chrome Extension MV3: Three isolated runtime contexts, message passing and Strategy Pattern: Read article
Docker Compose strategy: The override pattern, from local development to Azure: Read article
Ollama locally vs. Docker: The decision and its consequences: Read article
Ollama auto-pull entrypoint: Automated model setup at container startup: Read article
tsconfig and Vite: Node16 vs. bundler, and why Vite has its own rules: Read article
Load complete Instagram captions with MutationObserver: Read article
Chrome Extension foundation with health indicator and retry queue: Read article
Phase 2 features: Shadow DOM overlay, Tailwind v4 and duplicate detection: Read article
Race condition in platform detection: How a UI event breaks Instagram detection: Read article
Extracting PostId in two Instagram layouts: querySelector vs. ancestor traversal: Read article
Capture a complete Instagram carousel with MutationObserver: Lazy loading, observer-before-click and timeout fallback: Read article
Notes and tags when saving screenshots: Read article
Instagram keyboard shortcuts block Chrome Extension input: Read article
Lowercase normalization and duplicate detection in tag input: Read article
Zitadel Login V2 in Docker Compose with three hidden errors: Read article
PKCE OAuth in a Chrome MV3 extension: Read article
React frontend with react-oidc-context and Zitadel: Read article
Vite build-time environment variables in Docker: Read article
Event-driven ingestion with BullMQ and Redis: Read article
MinIO instead of Azurite: S3-compatible object storage locally and on Hetzner: Read article
access_token, id_token and the Userinfo endpoint: Which belongs where: Read article
Qdrant multi-tenancy with one collection per user: Read article
When backend and frontend know different types: Read article
Removing Zitadel bootstrap: Host header bug and manual setup: Read article
Backend code review with six problems fixed before launch: Read article
Traefik instead of NGINX: Reverse proxy for a growing Docker Compose stack: Read article
Two-layer rate limiting: Traefik and express-rate-limit with Redis: Read article
Implementing GDPR Article 17 correctly: Promise.allSettled and export batching: (this article)
Embedding model lock-in: Why mxbai-embed-large is a permanent production decision: Read article
Docker volumes in production: Named volumes, bind mounts and the Hetzner volume approach: Read article
Two vulnerabilities before launch: Redis without authentication and an exposed Qdrant admin port: Read article
Traefik as the single entry point in the Docker Compose stack: Read article
Connecting Zitadel behind Traefik with issuer, JWKS and Login V2: Read article
Fixing the frontend when the nginx healthcheck fails on localhost: Read article
Observability for my Docker Compose stack with Bull Board and Dozzle: Read article
Open the Qdrant dashboard securely with local Traefik and an SSH tunnel: Read article
Diagnosis of chunking failures despite tokenization: Read article
Why I set the chunk size to 1500 tokens: Read article
Splitting the embedding workflow into clear steps: Read article
Bringing chunking, storage and search back together: Read article
Capture Intake as a separate module, less orchestration in the Express endpoint: Read article