Skip to main content

Engineering

Designing a detection pipeline that survives the wait

· 3 min read
DeepFAIC Team
DeepFAIC Team
Engineering & Product

Separate submission, progress, and results so media analysis fits naturally into a reliable application workflow.

Media analysis takes time. A reliable integration treats that time as part of the workflow: the user can leave the page, a network request can fail, and the application can recover without losing track of the submission.

Both the documented cloud and Edge APIs use jobs, but their endpoint paths and response shapes differ. Choose the contract for your deployment and keep that distinction explicit in your client.

Give the application its own submission record​

Create an application record before handing work to the analysis service. Store the input reference, submission time, and intended processing configuration. Once job creation succeeds, attach the returned job ID.

Your application record is the anchor for the user experience. It can survive browser refreshes and let a background worker resume progress checks without depending on a single tab remaining open.

Model the lifecycle deliberately​

For Edge, the documented job lifecycle includes queued, processing, complete, and error. Your UI can translate those states into clear language, while preserving the original values for diagnostics.

Do not use “100% progress” as your only completion condition. Check the documented terminal status, handle errors explicitly, and retrieve the full record before presenting the final analysis.

Keep an application's request timeout separate from the processing lifecycle. A request that times out has an uncertain outcome; it does not prove that a submitted job was never created.

Poll the smaller response​

Progress checking should retrieve the information needed to show status. Edge provides a partial job endpoint for this purpose. Retrieve the full result when the job reaches completion, rather than repeatedly downloading detailed analysis throughout processing.

A production polling policy should include:

  • A bounded interval and a maximum wait duration appropriate to your workload.
  • Backoff and jitter after transient transport failures.
  • A clear response to authentication errors and invalid requests.
  • A way to resume checking an existing job instead of resubmitting its media.

The Edge tutorial uses a two-second polling interval to make the example easy to follow. Evaluate your own request volume and service limits before adopting that value across a fleet.

Be careful with retries at creation​

If the client loses the response after sending a create request, retrying may submit a second job. Do not assume an endpoint supports idempotency unless its contract documents it.

Record the attempted submission and reconcile the outcome where your integration allows it. Design your retry strategy separately for read requests and create requests; they do not have the same consequences.

Make completion useful​

When a job finishes, connect the result to the action in your product. That may be an analyst review, a request for a better input, or a policy decision. Preserve analysis errors and inconclusive results as distinct outcomes.

The best asynchronous workflow lets people see what is happening, lets the application recover, and keeps the final evidence tied to the original submission.

Start with the working Edge integration tutorial, then adapt persistence, retry, and polling policy to your application.