|
| 1 | +# Temporal + Stagehand Integration |
| 2 | + |
| 3 | +A best practices example showing how Temporal handles browser automation failures with automatic retries using atomic, idempotent activities. |
| 4 | + |
| 5 | +## What it does |
| 6 | + |
| 7 | +- Uses Stagehand to perform Google searches in a real browser |
| 8 | +- Each individual task is encapsulated within a Temporal Activity following best practices for atomicity and idempotency |
| 9 | +- If any individual task fails, Temporal will automatically retry it, resulting in reliable browser automation |
| 10 | +- Clean, maintainable code following Temporal patterns |
| 11 | + |
| 12 | +## Temporal Best Practices Demonstrated |
| 13 | + |
| 14 | +### Atomic Activities |
| 15 | +Each Temporal activity performs a single, well-defined task: |
| 16 | +1. **initializeBrowser** - Creates and initializes browser session |
| 17 | +2. **navigateToSearchPage** - Navigates to Google |
| 18 | +3. **executeSearch** - Types query and submits search |
| 19 | +4. **extractSearchResults** - Extracts and validates results |
| 20 | +5. **cleanupBrowser** - Closes browser session |
| 21 | +6. **formatResults** - Formats results for display |
| 22 | + |
| 23 | +### Why Atomic Activities? |
| 24 | +- **Efficient retries**: If extraction fails after search succeeds, only extraction is retried |
| 25 | +- **Better performance**: No need to repeat successful steps |
| 26 | +- **Clearer debugging**: Each activity's purpose is obvious |
| 27 | +- **Flexible retry policies**: Different activities can have different retry strategies |
| 28 | + |
| 29 | +### Idempotent Design |
| 30 | +- Browser sessions are reused if already initialized |
| 31 | +- Cleanup handles already-closed sessions gracefully |
| 32 | +- Navigation always results in the same state |
| 33 | +- Formatting produces consistent output |
| 34 | + |
| 35 | +## Setup |
| 36 | + |
| 37 | +1. Install dependencies: |
| 38 | +```bash |
| 39 | +npm install |
| 40 | +``` |
| 41 | + |
| 42 | +2. Set up environment variables in `.env`: |
| 43 | +``` |
| 44 | +BROWSERBASE_API_KEY=your_api_key |
| 45 | +BROWSERBASE_PROJECT_ID=your_project_id |
| 46 | +ANTHROPIC_API_KEY=your_anthropic_key # or OPENAI_API_KEY |
| 47 | +``` |
| 48 | + |
| 49 | +3. Start Temporal (if not already running): |
| 50 | +```bash |
| 51 | +temporal server start-dev |
| 52 | +``` |
| 53 | + |
| 54 | +## Running the Example |
| 55 | + |
| 56 | +1. Start the worker in one terminal: |
| 57 | +```bash |
| 58 | +npm run worker |
| 59 | +``` |
| 60 | + |
| 61 | +2. Run a search in another terminal: |
| 62 | +```bash |
| 63 | +npm run demo # Default search |
| 64 | +npm run demo "your search term" # Custom search |
| 65 | +``` |
| 66 | + |
| 67 | +## How it Works |
| 68 | + |
| 69 | +### Activities (`research-activities.ts`) |
| 70 | +Each activity is designed to be: |
| 71 | +- **Atomic**: Does one thing only |
| 72 | +- **Idempotent**: Can be safely retried |
| 73 | +- **Focused**: Clear single responsibility |
| 74 | + |
| 75 | +### Workflow (`workflows.ts`) |
| 76 | +- Orchestrates the atomic activities in sequence |
| 77 | +- Uses tailored retry policies for each activity type |
| 78 | +- Handles cleanup in a finally block |
| 79 | +- Provides clear progress logging |
| 80 | + |
| 81 | +### Worker (`research-worker.ts`) |
| 82 | +- Processes workflow tasks |
| 83 | +- Limits to 2 concurrent browser sessions |
| 84 | +- Simple configuration focused on essentials |
| 85 | + |
| 86 | +## Retry Behavior |
| 87 | + |
| 88 | +Each activity has a custom retry policy based on its characteristics: |
| 89 | + |
| 90 | +- **Initialize Browser**: 5 attempts, 2-10 second intervals |
| 91 | +- **Navigate**: 8 attempts, 1-5 second intervals (fast retries) |
| 92 | +- **Execute Search**: 10 attempts, 2-15 second intervals |
| 93 | +- **Extract Results**: 10 attempts, 3-20 second intervals (most likely to fail) |
| 94 | +- **Cleanup**: 3 attempts, 1-3 second intervals |
| 95 | +- **Format**: 2 attempts, minimal retry (deterministic) |
| 96 | + |
| 97 | +## Benefits |
| 98 | + |
| 99 | +- **Simplicity**: Clean code without complex error handling |
| 100 | +- **Efficiency**: Only failed steps are retried |
| 101 | +- **Reliability**: Temporal ensures tasks complete or fail definitively |
| 102 | +- **Visibility**: Monitor progress in Temporal Web UI at http://localhost:8233 |
| 103 | +- **Maintainability**: Each activity can be tested and updated independently |
| 104 | +- **Flexibility**: Easy to add new steps or modify retry behavior |
0 commit comments