fix(integrations): distinguish a transient Photon list failure from a stuck registration

The 409 re-key path read any missing match as "registered but Photon did not
return it" and told the operator to delete the webhook by hand — including when
the list call itself failed, where the right answer is simply to deploy again.
A failed listing now throws its own retry-shaped error before the match is
looked for, so manual cleanup is only ever advised for the state that actually
requires it, and nothing is deleted off a read that never succeeded.

Author: qwerzl

apps/sim/lib/webhooks/providers/photon-imessage.test.ts

@@ -535,6 +535,25 @@ describe('photonImessageHandler', () => {
       ).rejects.toThrow(/could not remove the stale registration/i)
     })
 
+    it('tells the operator to retry when listing webhooks fails, not to clean up by hand', async () => {
+      const fetchMock = vi.fn(async (_url: RequestInfo | URL, init?: RequestInit) => {
+        const method = init?.method ?? 'GET'
+        if (method === 'POST') return new Response(JSON.stringify({}), { status: 409 })
+        return new Response(JSON.stringify({}), { status: 503 })
+      })
+      vi.stubGlobal('fetch', fetchMock)
+
+      await expect(
+        photonImessageHandler.createSubscription!(subscriptionContext(CREDS))
+      ).rejects.toThrow(/listing webhooks to re-key it failed with status 503/i)
+      // A transient list failure must not read as the manual-cleanup case.
+      await expect(
+        photonImessageHandler.createSubscription!(subscriptionContext(CREDS))
+      ).rejects.not.toThrow(/dashboard/i)
+      // Nothing was deleted on a read that never succeeded.
+      expect(fetchMock.mock.calls.some((call) => call[1]?.method === 'DELETE')).toBe(false)
+    })
+
     it('fails clearly when Photon reports a conflict but does not list the webhook', async () => {
       const fetchMock = vi.fn(async (_url: RequestInfo | URL, init?: RequestInit) => {
         const method = init?.method ?? 'GET'

apps/sim/lib/webhooks/providers/photon-imessage.ts

@@ -324,17 +324,24 @@ export const photonImessageHandler: WebhookProviderHandler = {
       //
       // Every step is checked. Re-registering over a stale record that is still there just earns
       // another 409, so a failure here has to surface as the thing the operator can act on rather
-      // than as a second conflict with no explanation.
+      // than as a second conflict with no explanation — and a transient fault has to read as
+      // "try again", not as the manual cleanup that only an unrecoverable state calls for.
       logger.info(`[${requestId}] Photon webhook URL already registered; re-keying`)
 
       const listed = await photonWebhooksRequest(projectId, projectSecret, '')
+      if (listed.status >= 400) {
+        throw new Error(
+          `Photon reports ${webhookUrl} is already registered, but listing webhooks to re-key it failed with status ${listed.status}. Deploy again once Photon is reachable.`
+        )
+      }
+
       const existing = (Array.isArray(listed.body.data) ? listed.body.data : []).find(
         (record: PhotonWebhookRecord) => record.webhookUrl === webhookUrl
       ) as PhotonWebhookRecord | undefined
 
       if (!existing?.id) {
         throw new Error(
-          `Photon reports ${webhookUrl} is already registered but did not return it when listing webhooks (status ${listed.status}). Its signing secret can only be reissued by re-creating it — delete the webhook in the Photon dashboard, then deploy again.`
+          `Photon reports ${webhookUrl} is already registered but did not return it when listing webhooks. Its signing secret can only be reissued by re-creating it — delete the webhook in the Photon dashboard, then deploy again.`
         )
       }