General Info
When the Airtable API is unavailable or returns server-side errors, all failed sync requests must be queued instead of being lost.
The system must automatically retry queued requests when Airtable becomes available, while preventing duplicate records and preserving request order where required.
Client-side errors (4xx) must not block the queue indefinitely and should be logged for further investigation.
User story
As a system administrator
I want failed Airtable sync requests to be queued and retried automatically
So that no data is lost during Airtable outages and manual recovery is not required
|
#
|
Acceptance criteria
|
|
|
01
|
Scenario: Airtable API returns a server error (5xx)
Given the system sends a sync request to Airtable
When the API responds with a 5xx error (500, 502, 503)
Then the request is added to the fallback queue for retry
|
|
|
02
|
Scenario: Airtable API returns a client error (4xx)
Given a sync request fails with a 4xx error
When the response is received
Then the request is removed from the queue and the error details are logged for investigation
|
|
|
03
|
Scenario: Automatic retry of queued requests
Given there are queued sync requests
When Airtable becomes available again
Then the system retries queued requests automatically with a delay of 10–300 seconds between attempts
|
|
|
04
|
Scenario: Retry strategy without hard limit
Given a request continues to fail with 5xx errors
When retries are performed
Then retries continue without a fixed retry limit until the request succeeds or receives a 4xx error
|
|
|
05
|
Scenario: Successful sync processing
Given a queued request is resent
When Airtable responds with a 200 status
Then the request is removed from the queue and processing continues
|
|
|
06
|
Scenario: Prevent duplicate records during retries
Given a sync request is retried
When the record already exists in Airtable
Then the existing record is updated and no duplicate record is created
|
|
|
07
|
Scenario: Queue order preservation
Given multiple sync requests are queued
When retries are processed
Then requests are processed in the original order
|
|
|
08
|
Scenario: Queue monitoring and visibility
Given the fallback queue is active
When monitoring data is reviewed
Then the system provides visibility into pending items, last retry attempt, and last successful sync
|
|
|
09
|
Scenario: Queue behavior during infrastructure outages
Given Airtable or Cloudflare is unavailable
When sync requests fail
Then the queue accumulates requests without processing them until services are restored
|
|
|
10
|
Scenario: Manual intervention
Given an admin needs to intervene
When a manual trigger is executed
Then queued requests can be retried on demand
|
|
Leave a Reply
You must be logged in to post a comment.