DEV Community

Cover image for I Built a Fail-Fast Rust Scheduler with Background OAuth Auto-Refresh (Part 2)
freerave
freerave

Posted on

I Built a Fail-Fast Rust Scheduler with Background OAuth Auto-Refresh (Part 2)

#rust #typescript #architecture #webdev

In Part 1 of this backend series, I broke down the core architecture of dotsuite-core — a private Rust backend powering 18 developer tools, complete with multi-tier scheduling and the "Look-Ahead + Sleep" pattern.

But as with any production system, solving one architectural challenge reveals the next. In our case: Silent Scheduling Failures and Expiring OAuth Tokens.

Here is a deep dive into how we implemented a Strict Separation model, adopted a Fail-Fast philosophy, and engineered a background worker in Rust to automatically refresh OAuth tokens before they expire.

The Problem: Doomed Scheduled Posts

DotShare allows developers to schedule social media posts directly from VS Code. Initially, our scheduling flow looked like this:

  1. User writes a post in VS Code and clicks "Schedule".
  2. The Rust backend accepts the payload, deducts the monthly quota, and saves it as Pending in MongoDB.
  3. The background cron scheduler wakes up at the right time to publish.

The Flaw: What if the user hadn't connected their Twitter (X) or LinkedIn accounts via OAuth on the DotSuite dashboard yet?

The scheduler would wake up, search the database for the user's OAuth tokens, find nothing, and inevitably fail. The user's quota was burned, the database was polluted with doomed posts, and the user woke up to a silent failure.

Architecture Decision: Strict Separation & Fail-Fast

We needed a Strict Separation between local VS Code execution and Cloud Scheduling. If you want the cloud to schedule it, the cloud must have your OAuth tokens.

Instead of catching the error during the background cron tick, we applied the Fail-Fast principle right at the API gateway. The server must definitively verify the existence of the required platform credentials before doing anything else.

Here is the exact Rust code we added to our schedule_post route to enforce this:

// src/routes/posts.rs

// ── Pre-Quota: OAuth Credentials Validation ────────────────────────────
let creds_col = state.db.collection::<UserCredential>("user_credentials");

// Convert the requested platforms to BSON
let platforms_bson: Vec<bson::Bson> = body.platforms.iter()
    .map(|p| bson::to_bson(p).unwrap())
    .collect();

// Query MongoDB for existing credentials
let mut cursor = creds_col.find(doc! {
    "user_id": user_id,
    "platform": { "$in": platforms_bson }
}).await?;

let mut connected_platforms = std::collections::HashSet::new();
use futures_util::TryStreamExt;
while let Ok(Some(cred)) = cursor.try_next().await {
    connected_platforms.insert(cred.platform);
}

// Find exactly which platforms the user is missing
let missing_platforms: Vec<Platform> = body.platforms
    .iter()
    .filter(|&p| !connected_platforms.contains(p))
    .cloned()
    .collect();

if !missing_platforms.is_empty() {
    let names = missing_platforms.iter()
        .map(|p| format!("{:?}", p))
        .collect::<Vec<_>>()
        .join(", ");

    // Reject instantly before quota deduction!
    return Err(AppError::MissingOauth(
        format!("You haven't connected {} to DotSuite Cloud yet.", names),
        missing_platforms,
    ));
}
Enter fullscreen mode Exit fullscreen mode

By adding a custom MissingOauth error variant in our errors.rs, the Axum backend generates a beautifully structured JSON response:

{
  "error": {
    "code": "MISSING_OAUTH_CREDENTIALS",
    "message": "You haven't connected X, LinkedIn to DotSuite Cloud yet.",
    "missing_platforms": ["x", "linkedin"]
  }
}
Enter fullscreen mode Exit fullscreen mode

Premium UX in VS Code (TypeScript)

A structured error is only as good as the UX that presents it. In our VS Code extension, we intercept the MISSING_OAUTH_CREDENTIALS error code.

Instead of showing a generic "Server Error 400" toast, we display an actionable VS Code alert with an "Open Dashboard" button. This deep-links the developer straight into their DotSuite Cloud integration settings.

// DotShare/src/handlers/PostHandler.ts

const result = await SchedulerClient.schedulePost(context, postData, platforms, scheduledTime);

if (!result.success) {
    if (result.errorCode === 'MISSING_OAUTH_CREDENTIALS') {
        const action = 'Open Dashboard';
        vscode.window.showErrorMessage(
            '☁️ Cloud Scheduling requires secure OAuth. Please open the DotSuite Dashboard to connect your social accounts.',
            action
        ).then(selection => {
            if (selection === action) {
                // Deep link right to the login/integrations page
                const DOTSUITE_LOGIN_URL = `https://dotsuite.dev/en/login?intent=vscode`;
                vscode.env.openExternal(vscode.Uri.parse(DOTSUITE_LOGIN_URL));
            }
        });
    } else {
        vscode.window.showErrorMessage(`Failed: ${result.message}`);
    }
}
Enter fullscreen mode Exit fullscreen mode

Now, the server doesn't waste space on dead posts, quota remains untouched, and the user gets a seamless, enterprise-grade onboarding experience.

The Next Boss: Background Token Auto-Refresh

We solved the missing credentials problem, but OAuth tokens have notoriously short lifespans (often exactly 1 hour). If a user schedules a post for tomorrow, their token will be expired by the time the scheduler wakes up.

To fix this, we integrated auto-refresh logic directly into our scheduler.rs worker. Right before publishing a post, the scheduler checks the token's expires_at timestamp. If it expires in less than 5 minutes, it transparently refreshes the token via HTTP, saves the new encrypted tokens to the database, and proceeds with the publish cycle.

Here is the implementation:

// src/scheduler.rs

let now = DateTime::now();

// Check if token expires in less than 5 minutes
if now.timestamp_millis() > oauth_token.expires_at.timestamp_millis() - (5 * 60 * 1000) {
    tracing::info!("Refreshing OAuth token for platform {:?}", cred.platform);

    let refresh_token_str = oauth_token.refresh_token_encrypted.as_deref().unwrap_or("");

    // Fetch API keys from environment
    let cid = std::env::var(format!("{:?}_CLIENT_ID", cred.platform).to_uppercase()).unwrap_or_default();
    let csec = std::env::var(format!("{:?}_CLIENT_SECRET", cred.platform).to_uppercase()).unwrap_or_default();

    // Match the platform to its specific refresh logic via reqwest::Client
    let refresh_result = match cred.platform {
        Platform::X => refresh_x_token(&client, refresh_token_str, &cid, &csec, enc_key).await,
        Platform::LinkedIn => refresh_linkedin_token(&client, refresh_token_str, &cid, &csec, enc_key).await,
        Platform::Facebook => refresh_facebook_token(&client, refresh_token_str, &cid, &csec, enc_key).await,
        Platform::Reddit => refresh_reddit_token(&client, refresh_token_str, &cid, &csec, enc_key).await,
        _ => Err(anyhow::anyhow!("Platform unsupported for auto-refresh")),
    };

    if let Ok((new_access_enc, new_refresh_enc, expires_in)) = refresh_result {
        // 1. Decrypt and use the newly fetched token immediately
        let plain_access = crate::crypto::decrypt_token(&new_access_enc, enc_key).unwrap();
        tokens.insert(cred.platform, plain_access);

        // 2. Save the new encrypted tokens back to MongoDB atomically
        let new_expires_at = DateTime::from_millis(now.timestamp_millis() + (expires_in as i64 * 1000));
        let update_doc = doc! {
            "$set": {
                "oauth_token.access_token_encrypted": new_access_enc,
                "oauth_token.refresh_token_encrypted": if new_refresh_enc.is_empty() { None::<String> } else { Some(new_refresh_enc) },
                "oauth_token.expires_at": new_expires_at,
                "updated_at": DateTime::now(),
            }
        };

        creds_col.update_one(doc! { "_id": cred.id.unwrap() }, update_doc).await.unwrap();
        tracing::info!("✅ Successfully saved refreshed token for {:?}", cred.platform);
    }
}
Enter fullscreen mode Exit fullscreen mode

By decoupling the refresh logic into the background worker, the user never experiences HTTP round-trip delays when they click "Schedule" in VS Code. The tokens remain perpetually active as long as they are using the service, and everything happens completely behind the scenes.

Conclusion

By enforcing Strict Separation (validating cloud tokens explicitly on schedule) and leaning into the Fail-Fast design pattern, we protected our backend from pointless processing, saved the users' quotas, and improved the UX significantly.

Coupled with a resilient, auto-refreshing background job, the scheduling architecture is now as robust as the industry giants.

The biggest takeaway for your next API? Don't let your system silently fail. Stop the user at the gate, tell them exactly what they need to do with a structured JSON error, and give the frontend enough context to render a button that solves the problem for them!

(If you haven't read the previous deep dives, check out the full Ship on Schedule.)

Top comments (0)