Skip to main content
A Notebook stores a Python driver script and parameter definitions. Starting a run creates an instance using the code, arguments, and resource configuration at that time. Within the instance, the script decides when to compute, which inputs to process, which dependencies to wait for, and how to handle results. The instance and the remote compute tasks it submits have independent lifecycles. Understanding this relationship helps you choose resources, arrange continuous execution, and assess data state after a stop or restart.

​
Execution environment

Each Notebook instance runs in an isolated sandbox. Its CPU and memory limits come from the configuration at startup. Chaintable SDKs are preinstalled so the script can read tables, query chain state, and submit computations. Notebook resources support the driver script’s own work, such as preparing inputs and collecting results. Functions submitted to BlockX use separate compute resources; increasing Notebook CPU does not directly increase a function’s call budget. Notebook and Function SDK support may also differ. Write compute functions according to Execution environment and access boundaries.

​
Instance lifecycle

At startup, the system checks account capacity and saves the code, arguments, and resource configuration for that instance. Standard output, error logs, and resource usage are available in the UI. The instance ends when the script returns normally, raises an unhandled exception, is stopped, reaches its deadline, or is terminated for exceeding its memory limit. Editing a Notebook does not change an already running instance. Start a new instance to use new code. Subsequent scheduled runs use the saved script. Foreground execution requires the page to remain active. After switching to the background, the script can continue after you leave the page, but it is still subject to its runtime limit. To create subsequent instances automatically, use a timed or Continuous schedule. See Schedule for configuration. Continuous creates a new instance after the previous one exits and starts the script from its entry point. Python variables, in-memory caches, and loop positions are not restored. Persist results and processing progress that must survive a restart. For configuration shared across runs, use account runtime variables.

​
How driver scripts coordinate computation

Calling an ordinary Python function directly from the script executes it in the current instance. When you submit compute tasks through the BlockX SDK or a Pipeline, functions run in a separate compute environment while the Notebook waits for or collects task results. Compute functions should receive data through arguments and import their own dependencies. Notebook globals and existing client objects do not automatically become available to those functions. For example, a Pipeline processing block data follows these steps:
  1. Determine the available range. The script reads progress from its sources and dependency tables, limiting computation to blocks whose data is ready.
  2. Find gaps in the target table. Historical backfills use the target table’s processed ranges to select unfinished blocks.
  3. Submit compute tasks. Tasks generate function inputs from source records. BlockX executes calls in parallel while the script waits for or collects task status.
  4. Write results and record progress. The result handler writes returned records to the target table, and BlockDB maintains its block coverage. Processed blocks with no matching records must also leave a progress record.
  5. Keep following new data. After filling gaps, continuous updates subscribe to subsequent changes and repeat the process.
Dependencies and execution resources have separate roles: the Notebook decides when submission conditions are met, BlockX executes functions, and BlockDB records data and completion progress. Declaring dependencies prevents computation before source data is ready. Storing progress in the target table lets subsequent instances continue based on completed ranges. See Build a Pipeline for configuration.

​
Stopping and rerunning

Stopping a Notebook ends the driver instance, but does not mean that submitted compute tasks have also stopped. Completed writes are not rolled back. To determine what has been processed, check task results, target-table block coverage, and asynchronous write-job status, rather than relying only on whether the Notebook has stopped. When rerunning a script, use saved progress to determine the next inputs. Pipeline backfills use target-table coverage to skip completed blocks. If you submit tasks yourself, handle duplicate inputs and retries yourself; restarting an instance does not resume execution at a particular line of code.