refactor(tiktok): align webhook routing with shared dispatcher - #6261
refactor(tiktok): align webhook routing with shared dispatcher#6261BillLeoutsakosvl346 wants to merge 9 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
PR SummaryMedium Risk Overview Deploy now derives TikTok The Reviewed by Cursor Bugbot for commit 8d40ee4. Bugbot is set up for automated code reviews on this repo. Configure here. |
Greptile SummaryThe PR replaces TikTok-specific ingress and target-resolution jobs with the shared routing-key webhook dispatcher while retaining rollout compatibility through a routing-key migration.
Confidence Score: 5/5The PR appears safe to merge. The previously reported failed-dispatch issue is fixed: every failed shared-dispatch outcome is counted and causes a retryable 503 response, while intentionally ignored outcomes remain acknowledged.
|
| Filename | Overview |
|---|---|
| apps/sim/app/api/webhooks/tiktok/route.ts | Replaces provider-specific durable ingress with shared routing-key lookup and dispatch, and now returns 503 when any target dispatch fails. |
| apps/sim/lib/webhooks/deploy.ts | Persists the TikTok account open ID as the shared dispatcher routing key while retaining the temporary legacy fallback. |
| apps/sim/lib/credentials/deletion.ts | Extends credential cleanup to deactivate TikTok registrations bound through provider configuration. |
| packages/db/migrations/0282_tiktok_routing_key.sql | Backfills validated TikTok routing keys and adds the temporary fallback index needed during rolling deployment. |
| packages/db/schema.ts | Aligns the webhook schema indexes with TikTok routing-key lookup and rollout fallback behavior. |
Sequence Diagram
sequenceDiagram
participant TikTok
participant Route as TikTok webhook route
participant DB as Webhook lookup
participant Dispatcher as Shared dispatcher
participant Queue as Webhook execution queue
TikTok->>Route: Signed event
Route->>Route: Verify signature and envelope
Route->>DB: Find targets by user_openid + provider
DB-->>Route: Active workflow targets
loop Each target
Route->>Dispatcher: Dispatch resolved target
Dispatcher->>Queue: Enqueue webhook execution
Dispatcher-->>Route: queued / ignored / failed
end
alt Any dispatch failed
Route-->>TikTok: 503 retryable response
else All targets accepted or ignored
Route-->>TikTok: 200 OK
end
Reviews (2): Last reviewed commit: "refactor(tiktok): remove rollout compati..." | Re-trigger Greptile
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit df6065e. Configure here.
TikTok architecture classificationThis classifies the final TikTok integration after the routing cleanup.
StandardBlock
The normal integration block: operations, trigger options, fields, parameter mapping, and outputs. Tools
These follow the usual Triggers
These are conventional trigger definitions registered through Sim’s trigger registry. Registration and catalogs
These are the normal central registration, icon, generated-catalog, and documentation files used by other integrations. Semi-standardVideo-upload route
Uploading a video requires authenticated workspace-file access and streaming binary data to TikTok. That cannot be handled safely as an ordinary JSON tool request, so it uses the same internal-route pattern used by other file-backed integrations. App-level webhook handling
TikTok sends every application event to one shared callback rather than creating a URL per workflow. The provider-local route verifies TikTok’s signature and then uses Sim’s existing webhook dispatcher. Slack-style deployment and lifecycle integration
At deployment, Sim derives TikTok’s Credential deletion also deactivates TikTok deployments, matching the existing Slack lifecycle pattern. These shared files are touched only to register TikTok with established platform behavior; no new shared framework was introduced. OAuth and environment registration
These are established provider-registration points needed for TikTok OAuth credentials and webhook verification. UniqueThere is now no TikTok-specific runtime architecture under The only remaining unique files are one-time database history and cleanup:
Migration This belongs in the routing PR because the dead index and schema helper exist specifically because of the architecture being removed. Splitting it out would temporarily leave obsolete TikTok-only database infrastructure behind. The snapshot and journal changes are generated migration bookkeeping, not additional runtime design. Tests retained
These retain behavioral coverage for request/response transformation, bounded responses, upload streaming, authentication, routing, deployment isolation, idempotency, and credential cleanup. Low-value scope/output/registry restatements and all obsolete background-worker tests were removed. ResultThe final TikTok implementation is standard or semi-standard except for immutable migration history and the one-time removal of its obsolete index. Runtime webhook routing now follows the existing Slack-style dispatcher pattern. |

Summary
routingKeylookup and shared dispatcherrouting_keywith workspace/account verificationWhy
TikTok previously used provider-specific background ingress and target-resolution infrastructure. This aligns it with the established Slack-style shared-app webhook architecture while preserving authentication, filtering, idempotency, account isolation, and queued workflow execution.
The temporary fallback handles registrations written by old pods after the migration runs. A follow-up contract PR can remove that fallback and index after one full rollout and final backfill.
Validation
validate-triggerandvalidate-integrationreview: clean approvalgit diff --checkNo trigger options, tool behavior, OAuth scopes, webhook payloads, or user-facing fields change.