Hi! I keep seeing this message (see attached image...
# ask-a-descoper
n
Hi! I keep seeing this message (see attached image). We thought we fixed the issue but it keeps showing. Can you please help us to diagnose? What's going on there? I would assume that's related to the auditing connector
d
Hi, I'm Descope's AI assistant. I've put together an initial response below based on your question. --- ### What's Happening The audit streaming connector automatically pauses itself when the downstream endpoint returns non-2xx HTTP status codes (4xx or 5xx) multiple times consecutively. This is a protective measure to prevent continuous failed delivery attempts — and it triggers a toast notification in the Descope console each time it's detected. If the underlying issue hasn't been fully resolved, the connector can be re-enabled but will keep erroring and re-triggering the same notification. ### Common Root Causes to Check • Invalid or expired credentials — API keys, tokens, or secrets for the destination (e.g., Datadog, Splunk, New Relic) may have rotated or expired. • Endpoint URL is unreachable or misconfigured — the destination URL may be wrong or the service is down on their end. • AWS-specific: Missing or incorrect IAM role trust policy — can cause
is not authorized to perform: sts:AssumeRole
errors. • Permissions issue — the credentials used may no longer have write access to the destination bucket/index/endpoint. • Destination service outage — the third-party service itself may be returning 5xx errors intermittently. ### How to Diagnose 1. Check the logs of the destination service to see if there are any specific error messages that can provide more context. 2. Verify the credentials being used for the connection to ensure they are valid and have the necessary permissions. 3. Test the endpoint manually (e.g., using Postman or curl) to confirm it is reachable and responding correctly. 4. Review the configuration of the connector in Descope to ensure all settings are correct. 5. Monitor the service status of the third-party destination to check for any ongoing outages or issues. ### Additional Resources • Audit Trail Streaming • AWS S3 Connector • Audit & Troubleshooting Connectors
a
Hi @Nadav Yeheskel Help me to narrow this down faster, could you share a few details? 1. Which connector/destination are you streaming audits to? (e.g., Datadog, Splunk, AWS S3, New Relic, etc.) 2. What did you change when you "fixed" the issue the first time? (e.g., re-enabled the connector, rotated credentials, etc.) 3. In your Descope console, if you go to the connector settings, does it show any specific error message or status code alongside the notification? The fact that it keeps reappearing after a fix usually points to one of two things: • The connector gets re-enabled but the underlying auth/endpoint issue is still there, causing it to fail and pause again almost immediately • There's a recurring outage or rate-limit on the destination side causing intermittent failures If you can share the connector type and any error details from the console or destination logs, I should be able to pinpoint this quickly!
n
1. Audit connector. We use it to stream updates about edits in the descope to our backend 2. We found that our container was dying because of OOM. We increased the number of pods to 2 and increased the memory. 3. No The connector gets re-enabled because I keep clicking on "resume", but because that's still happening, we might have fixed another issue, but not this one. Since I know that you guys can see the logs of the connector (and that's lacking in the UI) - it could be great to understand what's the response you are getting. Maybe it can give me hint to the real issue
a
Hey Nadav, please DM me your project id
n
Done
a
Hi @Nadav Yeheskel I dug into the logs on our end and found the root cause. The issue is a payload schema mismatch — not related to your OOM fix. Your audit connector (
CI2xdaHyzajd0YVcFtcjZ3bcibVUu
) is consistently returning a 422 Validation Error from your backend:
Copy code
{
  "code": 422,
  "type": "VALIDATION_ERROR",
  "message": "Parameter validation error: /: must have required property 'events'"
}
Your backend endpoint expects the audit payload to be wrapped in an
events
property, but the data being sent doesn't match that structure. Since the 422 is a client-side error from your backend's validation, the connector keeps failing and auto-pausing — which is why resuming it doesn't stick. For fixing this issue you will need to update your backend webhook handler to accept the payload format that Descope sends, or add a mapping/transformation layer to wrap incoming data in the
events
field your schema requires. Let me know if this works for you!
n
Great. Do you have the call that fails? can you share that with me?
a
Hi Nadav! Sure — here's exactly what's happening. What Descope sends to your webhook:
Copy code
Each audit event is posted as an individual JSON object, like this:{
    "action": "FlowUpdated",
    "actor_id": "<mailto:user@company.com|user@company.com>",
    "occurred": "2024-01-15T14:30:22Z",
    "device": "Desktop",
    "browser": "Chrome",
    "correlation_id": "3mQK1PFzv6FIsNKDhrOhQD5BfWq",
    "data": { ... },
    "os": "macOS",
    "osVersion": "10.15.7"
}
Copy code
What your backend is responding with (422):{ "code": 422, "type": "VALIDATION_ERROR", "message": "must have required property 'events'" }
*The mismatch*_:_ Your backend's schema expects the payload to be wrapped in an
events
key (e.g.
{ "events": { ... } }
), but Descope sends the audit event object directly at the root level. To fix this, you'll need to update your webhook handler to accept the root-level format that Descope sends — either by removing the
events
requirement from your schema, or by adding a lightweight adapter/transformation layer in front of your endpoint that wraps the incoming payload before it hits your validator.
n
Is there a place where I can see the schema of all of the updates? I prefer to have validation if possible
If that's not difficult, it could be great to have the actual payload (with real data) that is causing the issue. We want to add tests for the fix
a
Unfortunately we don't log the outgoing request payload on our end, so we're unable to share the actual failed call data. That said, here's the full schema reference for all audit event types and fields which should have everything you need to write your tests and fix the validation: 📄 https://docs.descope.com/audit-trails-and-integrations/audit-events Let me know if you have any questions!
n
Thanks!