divine-mobile: Skill for Claude Code

Fastly Compute Async Request Reliability

Problem

Fire-and-forget HTTP requests from Fastly Compute@Edge using send_async silently fail because the worker process can terminate before the async request reaches the backend. Additionally, backend names referenced in code but not configured in the Fastly dashboard cause silent failures that are easy to miss.

Context / Trigger Conditions

• Background migration, webhook, or notification triggered via req.send_async(backend)
• The PendingRequest returned by send_async is immediately dropped (not awaited)
• The main response is sent to the client, causing the Compute worker to terminate
• Error is swallowed with let _ = ... or match ... { Err(_) => ... }
• Works in local testing (fastly compute serve) but fails in production
• Backend name in code doesn't match any backend in fastly backend list --service-id

Solution

1. Use synchronous send() instead of send_async() for critical operations

// BAD: Fire-and-forget — worker terminates before request completes
match req.send_async(BACKEND) {
    Ok(_pending) => {
        // PendingRequest dropped here — request likely never completes!
        Ok(())
    }
    Err(e) => { /* ... */ }
}

// GOOD: Synchronous send — waits for response
match req.send(BACKEND) {
    Ok(resp) => {
        let status = resp.get_status();
        if status.is_success() {
            eprintln!("[MIGRATE] Success for {}", hash);
        } else {
            eprintln!("[MIGRATE] Backend returned {}", status);
        }
        Ok(())
    }
    Err(e) => {
        eprintln!("[MIGRATE] Failed: {}", e);
        Ok(()) // Don't fail the main request
    }
}

2. When synchronous is too slow, use a caching layer

If a VCL caching layer fronts Compute (service chaining), the extra latency from synchronous send only affects cache misses. Subsequent requests hit the cache. This makes synchronous send acceptable for operations like migration triggers.

3. Always verify backend existence