Getting Started
Core Architecture
Link Engine
Analytics & Attribution
Partners & Affiliates
Third-Party Integrations
Identity & Security
Automation & Messaging
Developer Tools
The following files were used as context for generating this wiki page:
This page documents the end-to-end execution flow when a partner deletion cron request (POST) triggers side-effect cleanups, unlinking, and eventually interacts with the Turbopuffer search provider via createNamespace.
When a partner is permanently deleted from a program, the system must clean up associated database rows, delete related short links in bulk, and queue an index synchronization task with the external vector and search database (Turbopuffer). This flow ensures that search indices remain consistent and reflect deleted enrollments without blocking the primary mutation.
Sources: apps/web/app/(ee)/api/cron/partners/delete/route.ts:20-184
The entry point is the cron route handler which receives a JSON body containing , , , and . After validating the input schema and ensuring the partner enrollment and its associated links and tags exist, the handler verifies deletion constraints (such as checking for zero active commissions or payouts). It clears related relational records (submitted leads, fraud events, messages) and invokes bulk link deletion if any links are attached to the enrollment.
workspaceIdprogramIdpartnerIduserIdCalled by the delete route when links.length > 0, the bulkDeleteLinks function processes links in batches of 100. For each batch, it identifies and removes related discount codes, executes a database transaction to delete the link records, and decrements the project's total link counter. Finally, it schedules asynchronous cleanups for Redis cache entries, Tinybird analytics records, R2 storage images, and queues partner search synchronization if any deleted links were associated with a partner.
As part of the asynchronous cleanup following link deletion, queuePartnerSearchSyncForLinks maps over the deleted links that carry a partnerId and programId. It aggregates partner IDs by their respective program IDs to prevent redundant job creation, subsequently delegating each grouped program batch to the search sync queue.
The core queuing function, queuePartnerSearchSync, validates that a search provider is actively configured. It chunks enrollment IDs and partner IDs into batch payloads and attempts to dispatch them to the partnerSearchSyncJob queue with a 5-second default delay. This delay ensures database mutations have fully committed before background workers attempt to read the rows back.
To interact with the search service, getPartnerSearchProvider checks for the presence of the TURBOPUFFER_API_KEY environment variable. If configured, it initializes and caches a singleton instance of the Turbopuffer search provider, avoiding repeated TLS handshakes and connection pool overhead across requests.
The provider factory initializes the Turbopuffer integration wrapper. It exposes methods for searching candidates, counting results, upserting documents, and removing document IDs. Behind the scenes, these methods reference a shared vector namespace (defaults to partner-search-v4) where partner program data is indexed.
Sources: apps/web/lib/api/partners/search/providers/turbopuffer.ts:34-36, apps/web/lib/api/partners/search/providers/turbopuffer.ts:345-421
When provider operations require access to Turbopuffer, createNamespace instantiates the official @turbopuffer/turbopuffer client configured with the API key and the aws-us-east-1 region. It returns the requested namespace object (e.g., partner-search-v4), allowing write, query, and delete operations to execute against the remote index.
Sources: apps/web/app/(ee)/api/cron/partners/delete/route.ts:20-163, apps/web/lib/api/links/bulk-delete-links.ts:23-73, apps/web/lib/api/partners/queue-partner-search-sync.ts:44-125, apps/web/lib/api/partners/search/provider.ts:12-20, apps/web/lib/api/partners/search/providers/turbopuffer.ts:123-136, apps/web/lib/api/partners/search/providers/turbopuffer.ts:345-351
Sources: apps/web/app/(ee)/api/cron/partners/delete/route.ts:49-163, apps/web/lib/api/links/bulk-delete-links.ts:31-73, apps/web/lib/api/partners/queue-partner-search-sync.ts:52-83, apps/web/lib/api/partners/search/provider.ts:12-20, apps/web/lib/api/partners/search/providers/turbopuffer.ts:123-136
queuePartnerSearchSync) is designed to catch dispatch failures without failing the primary source mutation. If QStash dispatch throws, errors are logged gracefully while allowing the core HTTP response to proceed.cachedSearchProvider), which prevents connection overhead and TLS handshake degradation during frequent search and synchronization updates.