Complex DAG testing workflows with debugging and fixing cycles. Use for multi-step testing requests like "test this dag and fix it if it fails", "test and debug", "run the pipeline and troubleshoot issues". For simple test requests ("test dag", "run dag"), the airflow entrypoint skill handles it dir

DAG Testing Skill Use af commands to test, debug, and fix DAGs in iterative cycles. Running the CLI These commands assume af is on PATH. Run via astro otto to get it automatically, or install standalone with uv tool install astro airflow mcp . Quick Validation with Astro CLI If the user has the Astro CLI available, these commands provide fast feedback without needing a running Airflow instance: Use these for quick validation during development. For full end to end testing against a live Airflow instance, continue to the trigger and wait workflow below. FIRST ACTION: Just Trigger the DAG When the user asks to test a DAG, your FIRST AND ONLY action should be: DO NOT: Call af dags list first Call af dags get first Call af dags errors first Use grep or ls or any other bash command Do any "pre flight checks" Just trigger the DAG. If it fails, THEN debug. Testing Workflow Overview Philosophy: Try first, debug on failure. Don't waste time on pre flight checks — just run the DAG and diagnose if something goes wrong. Phase 1: Trigger and Wait Use af runs trigger wait to test the DAG: Primary Method: Trigger and Wait Example: Why this is the preferred method: Single command handles trigger + monitoring Returns immediately when DAG completes (success or failure) Includes failed task details if run fails No manual polling required Response Interpretation Success: Failure: Timeout: Alternative: Trigger and Monitor Separately Use this only when you need more control: Handling Results If Success The DAG ran successfully. Summarize for the user: Total elapsed time Number of tasks completed Any notable outputs (if visible in logs) You're done! If Timed Out The DAG is still running. Options: 1. Check current status: af runs get <dag id <dag run id 2. Ask user if they want to continue waiting 3. Increase timeout and try again If Failed Move to Phase 2 (Debug) to identify the root cause. Phase 2: Debug Failures (Only If Needed) When a DAG run fails, use these commands to diagnose: Get Comprehensive Diagnosis Returns in one call: Run metadata (state, timing) All task instances with states Summary of failed tasks State counts (success, failed, skipped, etc.) Get Task Logs Example: For specific retry attempt: Look for: Exception messages and stack traces Connection errors (database, API, S3) Permission errors Timeout errors Missing dependencies Check Upstream Tasks If a task shows upstream failed , the root cause is in an upstream task. Use af runs diagnose to find which task actually failed. Check Import Errors (If DAG Didn't Run) If the trigger failed because the DAG doesn't exist: This reveals syntax errors or missing dependencies that prevented the DAG from loading. Phase 3: Fix and Retest Once you identify the issue: Common Fixes Issue Fix Missing import Add to DAG file Missing package Add to requirements.txt Connection error Check af config connections , verify credentials Variable missing Check af config variables , create if needed Timeout Increase task timeout or optimize query Permission error Check credentials in connection After Fixing 1. Save the file 2. Retest: af runs trigger wait <dag id Repeat the test → debug → fix loop until the DAG succeeds. CLI Quick Reference Phase Command Purpose Test af runs trigger wait <dag id Primary test method — start here Test af runs trigger <dag id Start run (alternative) Test af runs get <dag id <run id Check run status Debug af runs diagnose <dag id <run id Comprehensive failure diagnosis Debug af tasks logs <dag id <run id <task id Get task output/errors Debug af dags errors Check for parse errors (if DAG won't load) Debug af dags get <dag id Verify DAG config Debug af dags explore <dag id Full DAG inspection Config af config connections List connections Config af config variables List variables Testing Scenarios Scenario 1: Test a DAG (Happy Path) Scenario 2: Test a DAG (With Failure) Scenario 3: DAG Doesn't Exist / Won't Load Scenario 4: Debug a Failed Scheduled Run Scenario 5: Test with Custom Configuration Scenario 6: Long Running DAG Debugging Tips Common Error Patterns Connection Refused / Timeout: Check af config connections for correct host/port Verify network connectivity to external system Check if connection credentials are correct ModuleNotFoundError: Package missing from requirements.txt After adding, may need environment restart PermissionError: Check IAM roles, database grants, API keys Verify connection has correct credentials Task Timeout: Query or operation taking too long Consider adding timeout parameter to task Optimize underlying query/operation Reading Task Logs Task logs typically show: 1. Task start timestamp 2. Any print/log statements from task code 3. Return value (for @task decorated functions) 4. Exception + full stack trace (if failed) 5. Task end timestamp and duration Focus on the exception at the bottom of failed task logs. On Astro Astro deployments support environment promotion, which helps structure your testing workflow: Dev deployment : Test DAGs freely with astro deploy dags for fast iteration Staging deployment : Run integration tests against production like data Production deployment : Deploy only after validation in lower environments Use separate Astro deployments for each environment and promote code through them Related Skills authoring dags : For creating new DAGs (includes validation before testing) debugging dags : For general Airflow troubleshooting deploying airflow : For deploying DAGs to production after testing

testing-dags