Skip to main content

Wait Table

Waits until a new table matching the pattern is created in the database. This node blocks execution until the condition is met.

Common Properties​

  • Name - The custom name of the node.
  • Color - The custom color of the node.
  • Delay Before (sec) - Waits in seconds before executing the node.
  • Delay After (sec) - Waits in seconds after executing node.
  • Continue On Error - Automation will continue regardless of any error. The default value is false.
info

If the ContinueOnError property is true, no error is caught when the project is executed, even if a Catch node is used.

Inputs​

  • Connection Id - The unique identifier of the database connection to use (optional if credentials provided directly).
  • Table Name - The table name pattern to monitor. Can include schema name (e.g., schema.table) and supports LIKE wildcards (%, _).

Options​

  • Poll Time (s) - Time interval in seconds between checks for new tables. Default: 1.0 second.
  • Credentials - MySQL database credentials (optional). Use this if you want to wait without a Connect node.
  • Parameters - Additional connection string parameters (optional). Only used when credentials are provided.

Output​

  • None - The node completes when a new table matching the pattern is detected.

How It Works​

The Wait Table node monitors the database for new tables. When executed, the node:

  1. Retrieves the database connection (either from connection ID or creates new connection from credentials)
  2. Validates the table name pattern is not empty
  3. Constructs a SQL query to count tables matching the pattern
  4. On first check, records the current count of matching tables (baseline)
  5. Polls the database at the specified interval
  6. Compares the current count with the baseline
  7. Continues execution when the count increases (new table created)
  8. Blocks the flow until the condition is met

Requirements​

  • Either: A valid connection ID from Connect node OR valid database credentials
  • Valid table name or pattern
  • Database user must have SELECT permission on INFORMATION_SCHEMA.TABLES
  • Active database connection during the wait period

Error Handling​

The node will return specific errors in the following cases:

  • ErrInvalidArg - Table name pattern is empty
  • ErrNotFound - Connection ID not found

Table Name Patterns​

Exact Table Name​

Table Name: users

Waits for a table named exactly "users" to be created.

Table with Schema​

Table Name: mydb.users

Waits for table "users" in schema "mydb".

Wildcard Patterns​

Table Name: temp_%

Waits for any table starting with "temp_" (e.g., temp_data, temp_report).

Table Name: %_log

Waits for any table ending with "_log" (e.g., access_log, error_log).

Table Name: report_%

Waits for any table starting with "report_".

Schema with Wildcard​

Table Name: mydb.temp_%

Waits for any table starting with "temp_" in schema "mydb".

Usage Examples​

Wait for Specific Table​

Connect
  ↓
Wait Table
  - Table Name: import_data
  - Poll Time: 2.0
  ↓
Query (process new table)
  - SELECT * FROM import_data
  ↓
Disconnect

Wait for ETL Table​

Connect
  ↓
Wait Table (wait for external ETL process to create table)
  - Table Name: staging_orders_%
  - Poll Time: 5.0
  ↓
Query (retrieve data from new staging table)
  ↓
Insert Table (move data to production)
  ↓
Non Query (drop staging table)
  ↓
Disconnect

Monitor Schema Changes​

Connect
  ↓
Wait Table
  - Table Name: mydb.audit_%
  - Poll Time: 1.0
  ↓
Query (analyze new audit table)
  ↓
Send Email (notify new audit table created)
  ↓
Disconnect

Common Use Cases​

  1. ETL Coordination - Wait for ETL process to create staging tables
  2. Data Pipeline - Synchronize between different automation steps
  3. External Process Integration - Wait for external applications to create tables
  4. Schema Monitoring - Monitor for unexpected table creation
  5. Batch Processing - Wait for batch jobs to create result tables
  6. Dynamic Table Creation - React to dynamically created tables
  7. Multi-System Synchronization - Coordinate between systems using database as signal

Polling Behavior​

Initial Baseline​

On the first check, the node:

  1. Counts current tables matching the pattern
  2. Stores this count as the baseline
  3. Continues polling

Subsequent Checks​

On each poll:

  1. Counts current tables matching the pattern
  2. Compares with baseline
  3. If count increased → new table detected → node completes
  4. If count same or decreased → continues polling

Poll Interval​

The Poll Time option controls how often the database is checked:

  • Lower values (0.5s) - More responsive but higher database load
  • Higher values (5s) - Less database load but slower to detect

Tips for Effective Use​

  • Poll Time Balance - Balance responsiveness vs database load
  • Specific Patterns - Use specific patterns to avoid false triggers
  • Schema Qualification - Include schema name to avoid ambiguity
  • Timeout Handling - Implement timeout logic if table might not be created
  • Connection Management - Ensure connection stays alive during long waits
  • Pattern Testing - Test patterns with SHOW TABLES LIKE 'pattern' first
  • Monitoring - Log when waiting starts and ends for debugging

Best Practices​

With Timeout​

Connect
  ↓
Parallel
  ├─ Wait Table (wait for table)
  │   - Table Name: import_data
  └─ Delay (timeout after 5 minutes)
      - Delay: 300 seconds
  ↓
If (Wait Table completed first)
  └─ Process table
Else
  └─ Log timeout and alert
  ↓
Disconnect

Monitor Multiple Patterns​

Loop (over patterns: ['temp_%', 'import_%', 'staging_%'])
  ↓
  Wait Table
    - Table Name: {{pattern}}
    ↓
  Log (table matching {{pattern}} detected)

ETL Pipeline Coordination​

System A creates table → System B waits → System B processes

System B Flow:
Connect
  ↓
Wait Table
  - Table Name: etl_output_{{jobId}}
  - Poll Time: 5.0
  ↓
Query (get table data)
  ↓
Process Data
  ↓
Non Query (drop temp table)
  ↓
Disconnect

Integration with External System​

Connect
  ↓
Loop (continuous monitoring)
    ↓
    Wait Table (wait for external system)
      - Table Name: external_import_%
      - Poll Time: 10.0
      ↓
    Query (get table name)
      ↓
    Process Data
      ↓
    Archive or Delete Table
      ↓
    Reset for next iteration

Performance Considerations​

  • Poll Frequency - More frequent polling increases database load
  • Pattern Complexity - Complex LIKE patterns may be slower to evaluate
  • Table Count - Large numbers of tables increase query time
  • Connection Overhead - Keep connection open to avoid reconnection overhead
  • Index Usage - INFORMATION_SCHEMA queries are generally fast

Common Errors and Solutions​

Table Name Pattern Cannot Be Empty​

Error: ErrInvalidArg: Table name pattern cannot be empty

Solutions:

  • Provide a valid table name or pattern
  • Ensure the variable containing the pattern has a value

Connection Not Found​

Error: ErrNotFound: Connection not found

Solutions:

  • Ensure Connect node runs before Wait Table
  • Verify connection ID is correct
  • Or use Credentials option to connect directly

Timeout or Infinite Wait​

Issue: Node waits indefinitely if table is never created

Solutions:

  • Implement timeout using Parallel node with Delay
  • Add maximum iteration count if in a loop
  • Monitor and alert if wait exceeds expected time

False Positives​

Issue: Node triggers on unexpected tables

Solutions:

  • Use more specific table name patterns
  • Include schema name to narrow scope
  • Use exact table names instead of wildcards when possible

Advanced Examples​

Wait and Process Multiple Tables​

// JavaScript to get all new tables
const tables = await query(`
  SELECT TABLE_NAME
  FROM INFORMATION_SCHEMA.TABLES
  WHERE TABLE_SCHEMA = 'mydb'
    AND TABLE_NAME LIKE 'import_%'
`);

// Process each table
for (const table of tables) {
  // Process table.TABLE_NAME
}

Conditional Processing​

Wait Table
  - Table Name: process_%
  ↓
Query (get table name)
  - SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
    WHERE TABLE_NAME LIKE 'process_%'
    ORDER BY CREATE_TIME DESC LIMIT 1
  ↓
JavaScript (determine processing based on table name)
  ↓
If (table contains 'urgent')
  └─ Priority Processing
Else
  └─ Normal Processing

Multi-Stage Pipeline​

Stage 1: External system creates input_data table
  ↓
Stage 2: Wait Table (input_data)
  ↓
Stage 3: Process and create staging_data table
  ↓
Stage 4: Wait Table (staging_data) in another flow
  ↓
Stage 5: Final processing

Schema Evolution Monitoring​

Connect
  ↓
Loop (continuous monitoring)
    ↓
    Wait Table
      - Table Name: %
      - Poll Time: 30.0
      ↓
    Query (get details of new table)
      - SHOW CREATE TABLE {{tableName}}
      ↓
    Log table creation event
      ↓
    Send notification
      ↓
    Update schema documentation

Polling Query​

The node uses this query internally:

Without Schema​

SELECT COUNT(*)
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME LIKE 'pattern'

With Schema​

SELECT COUNT(*)
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'schema'
  AND TABLE_NAME LIKE 'pattern'

Alternatives​

If Wait Table doesn't fit your use case:

Polling Loop​

Loop (with delay)
    ↓
    Query (check if table exists)
      - SELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES
        WHERE TABLE_NAME = 'tablename'
      ↓
    If (count > 0)
      └─ Break Loop
    Else
      └─ Delay and continue

Event-Driven​

If the external system can trigger your flow:

  • Use HTTP trigger
  • Use file system trigger
  • Use message queue

See Also​

  • Wait Row - Wait for new rows in a table
  • Wait Column - Wait for new columns in a table
  • Connect - Establish database connections
  • Query - Query table information