test(webhooks): pin the pre-lookup handshake order

The inversion fixed in the previous commit passed every existing test, because
nothing asserted where the challenge offer sits relative to the load-shed gate
or to the setup-verification probe. Both are answered from the request alone,
so the ordering is the whole behavior and no other assertion touches it.

Covers the two symptoms directly: a challenge is answered without taking an
admission ticket, and it is offered before the verification probe rather than
after. Reintroducing the inverted order fails both.

Author: waleedlatif1

apps/sim/app/api/webhooks/trigger/[path]/route.test.ts

@@ -462,6 +462,10 @@ vi.mock('postgres', () => vi.fn().mockReturnValue({}))
 
 process.env.DATABASE_URL = 'postgresql://test:test@localhost:5432/test'
 
+import {
+  handlePreLookupWebhookVerification,
+  handleProviderChallenges,
+} from '@/lib/webhooks/processor'
 import { DELETE, GET, PATCH, POST, PUT } from '@/app/api/webhooks/trigger/[path]/route'
 
 describe('Webhook Trigger API Route', () => {
@@ -683,6 +687,60 @@ describe('Webhook Trigger API Route', () => {
     })
   })
 
+  /**
+   * Both handshakes are answered from the request alone, before any webhook lookup, so their
+   * order relative to each other and to the load-shed gate is the behavior — and it is invisible
+   * to every other test here, which is how an earlier refactor inverted it unnoticed.
+   */
+  describe('pre-lookup handshake ordering', () => {
+    /**
+     * Meta verifies a WhatsApp URL with a GET challenge. Answering it behind the load-shed gate
+     * means a busy instance returns 429 and the webhook silently fails to verify, at setup time
+     * only — so the challenge must be answered without taking a ticket at all.
+     */
+    it('answers a provider challenge without taking an admission ticket', async () => {
+      vi.mocked(handleProviderChallenges).mockResolvedValueOnce(
+        new NextResponse('hub-challenge-123', { status: 200 })
+      )
+
+      const req = createMockRequest(
+        'GET',
+        undefined,
+        {},
+        'http://localhost:3000/api/webhooks/trigger/verify-path?hub.challenge=hub-challenge-123'
+      )
+
+      const response = await GET(req, { params: Promise.resolve({ path: 'verify-path' }) })
+
+      expect(response.status).toBe(200)
+      await expect(response.text()).resolves.toBe('hub-challenge-123')
+      expect(tryAdmitMock).not.toHaveBeenCalled()
+    })
+
+    /**
+     * A challenge is the more specific answer: the provider is echoing a token it chose, where a
+     * pending verification only claims the URL is reachable. Answering the generic 200 first
+     * fails the handshake that actually had a token to return.
+     */
+    it('prefers a provider challenge over a pending setup verification', async () => {
+      vi.mocked(handleProviderChallenges).mockResolvedValueOnce(
+        new NextResponse('hub-challenge-123', { status: 200 })
+      )
+
+      const req = createMockRequest(
+        'GET',
+        undefined,
+        {},
+        'http://localhost:3000/api/webhooks/trigger/verify-path?hub.challenge=hub-challenge-123'
+      )
+
+      const response = await GET(req, { params: Promise.resolve({ path: 'verify-path' }) })
+
+      await expect(response.text()).resolves.toBe('hub-challenge-123')
+      expect(handlePreLookupWebhookVerification).not.toHaveBeenCalled()
+    })
+  })
+
   describe('GET deliveries', () => {
     it('dispatches a GET delivery to a generic webhook', async () => {
       testData.webhooks.push({