Skip to content
Doppelganger logo

Task History & Rollbacks

Doppelganger’s task versioning isn’t just a history log—it’s a foundational part of your automation workflow. Every task you build, test, or publish can be traced, audited, and restored. Properly leveraging versions ensures reliability, accountability, and maintainability across small scripts and large-scale automation pipelines. Here’s a comprehensive look at why versioning matters and how to integrate it as a first-class part of your workflow.

Why Version Tasks?#

Versioning in Doppelganger isn’t optional—it’s critical for any production-ready automation. Here’s why:

  1. Reproducibility
    Every task captures a series of precise actions: clicks, types, waits, variable states, and even stealth settings (like user-agent spoofing or natural typing). By saving a task version, you create a snapshot of exactly how the task was executed. Later, even if your goal changes or elements on the site update, you can restore that version to reproduce prior results exactly.

    Example: You optimized a web scraping task that bypasses a lazy-loaded banner. Weeks later, the site changes—restoring the working version ensures your extraction still runs correctly.

  2. Auditing
    When tasks are reviewed manually or through CI/CD pipelines, versioning provides a diffable, timestamped history of changes. This is critical for troubleshooting: you can quickly compare “what worked on Tuesday” versus “what broke today.”

    Example: Your extraction failed on a product page. Comparing versions reveals the CSS selector changed—without version history, diagnosing the issue would be guesswork.

  3. Rollback
    Updates can break tasks. Versioning allows you to roll back to a known-good configuration without losing prior experimentation. The failed version is still preserved for analysis, creating a complete audit trail.

    Example: Switching from agent to scrape mode caused a task to fail. Restore the previous version, test it, and iterate safely.

How Versions Are Created#

  • Every Save operation or persistent task run sends the full task JSON payload to the server. This includes metadata (task name, description, last opened), execution mode (scrape, agent, headful), actions array, selectors, stealth flags, variables, and extraction settings.
  • The server assigns a timestamp and a unique version ID.
  • Versions are immutable—any edit creates a new snapshot rather than overwriting history.

This ensures every action is traceable and that no historical state can be accidentally lost.

Timeline in the UI#

  1. Editor History Panel
    Access via the History button in the top-right corner of the task editor. Versions are displayed vertically, most recent first, making navigation fast.

  2. Preview & Diff
    Selecting a version loads it in a read-only editor preview. Changes are highlighted: inserts, deletes, and config modifications.

  3. Restore / Use
    Clicking Restore replaces the live task with that version, which then itself becomes a new version when saved. You can also copy the JSON from a version to feed into scripts, APIs, or external tools.

Operational Guidance#

  • Save before sharing: Always hit Save before exporting JSON or sharing. This locks the configuration and ensures collaborators receive a precise snapshot.

  • Use version comments: Embed context in action values or variable names, e.g., "switchToNewSelector_banner". The diff view surfaces these edits clearly.

  • Track safe vs draft states: The editor tracks hasUnsavedChanges. Only intentional edits create versions, reducing clutter.

  • Combine with branches: Treat task versions like git commits. Teams sharing tasks through presets can reference version IDs as release notes or deployment checkpoints.

Security and Compliance#

  • Every version is audit-ready. In regulated environments, attach execution logs or IDs to versions to prove what data was collected and what selector logic was used.

  • In automation pipelines, log the version ID alongside the run ID to ensure traceability from execution back to the editor history.

Advanced Usage#

  1. Automated Rollbacks
    Script queries GET /api/tasks/:id/versions to find the most recent passing version (status: success) and POST that payload as the next task to restore it automatically.

  2. Changelog Generation
    Iterate through the version history to produce human-readable summaries (e.g., "stealth.naturalTyping toggled on") for release logs.

  3. Third-Party Synchronization
    Share tasks by version ID and JSON payload. Recipients can import directly into the editor to reproduce exact automation behavior.

Best Practices#

  • Treat every Save like a commit.
  • Treat every version like a tag.
  • Treat version history as your safety net.

This mindset unlocks reliable automation, faster recovery, and clearer collaboration, making complex workflows maintainable at scale.

Previous
Next