Goal
Understand signature validation, filtering, asynchronous processing, retries, and duplicate delivery in event-driven integrations.Prerequisites
No special prerequisites.Delivery flow
1
Event is produced
The source platform emits an event such as a push or merge request.
2
Signature is validated
PawSQL verifies the payload signature or shared secret and rejects invalid deliveries.
3
Payload is filtered
PawSQL ignores events outside the repository, branch, path, and event scope.
4
Job is created
A review job is queued with the workspace and policy mapped from the event.
5
Result is returned
The gate decision and report link are published to the source platform.
Security model
- Signature validation — verify the shared secret or signing key on every delivery.
- Replay protection — record processed event identifiers and timestamps.
- TLS — require HTTPS and validate certificates.
- Source allowlist — accept deliveries only from expected sources and networks.
- Secret handling — store secrets in a managed vault; never log them.
Retries and duplicate delivery
Source platforms may retry a delivery when the endpoint is unavailable or slow. PawSQL treats these as the same logical event:- Duplicate deliveries are idempotent and do not create duplicate reviews or feedback.
- Retries are bounded; an event is recorded as failed after the platform’s retry window.
- Endpoint errors follow the platform’s retry policy and backoff.
Filtering and processing
The review scope reduces noise and cost by limiting what the integration processes:- Restrict repositories, branches, and event actions.
- Select SQL paths, file extensions, and database dialects.
- Ignore removed files and non-SQL changes.
- Map the event to the correct workspace and review policy.
Operation notes
- Monitor delivery latency and the queue depth.
- Alert when the failure rate exceeds a threshold.
- Keep endpoint availability high to avoid triggering retries.
- Review processed event logs to confirm correct scope.