@blinklabs/dingo 0.20.0 → 0.23.0

package/RELEASE_NOTES.md

@@ -0,0 +1,91 @@
+# Release Notes
+
+## v0.22.1 (March 8, 2026)
+
+**Title:** Stability updates and polish
+
+**Date:** March 8, 2026
+
+**Version:** v0.22.1
+
+Hi folks! Here’s what we shipped in v0.22.1.
+
+### ✨ What's New
+
+- **Release notes:** We added v0.22.0 release notes to `RELEASE_NOTES.md` so you can scan changes in one place.
+
+### 💪 Improvements
+
+- **Transaction validation:** Transaction validation is more consistent because Conway UTxO validation now runs even when a transaction is marked invalid, while script evaluation is still skipped.
+- **Epoch processing:** Epoch processing recovers more gracefully because nonce recomputation falls back to recomputing from epoch start when an anchor block nonce is missing.
+- **Queue handling:** Queue handling is more solid under load because the main event queue size increased from 1,000 to 10,000 and the header queue size is now clamped to at least the default.
+- **Implausible-tip checks:** Implausible-tip checks are safer across edge cases because the logic now uses peer-based reference blocks with overflow-safe arithmetic.
+- **Publish workflow login:** Publishing is more rock-solid because the publish workflow was tweaked to log in using `docker/login-action@v4`.
+- **Publish workflow runtime:** Automation stays more up to date because Node.js `24.x` was rolled out for the publish workflow.
+
+### 🔧 Fixes
+
+- **Epoch cache rollbacks:** Epoch cache handling is safer during concurrent rollbacks because `advanceEpochCache` now guards against empty caches and validates the tail before appending a new epoch.
+- **Test timing:** Tests are less flaky on slower machines because `TestSchedulerRunFailFunc` timing parameters were relaxed.
+
+### 📋 What You Need to Know
+
+- **API bind address:** Config validation no longer defaults the API bind address to `0.0.0.0`, so set it explicitly if you need it.
+- **CI and publishing scripts:** If you maintain custom publishing or CI scripts, give them a quick check for compatibility with Node.js `24.x` and `docker/login-action@v4`.
+
+### 🙏 Thank You
+
+Thank you for trying!
+
+---
+
+## v0.22.0 (March 7, 2026)
+
+**Title:** Mithril bootstrap, built-in APIs, and block production
+
+**Date:** March 7, 2026
+
+**Version:** v0.22.0
+
+Hi folks! Here’s what we shipped in v0.22.0.
+
+### ✨ What's New
+
+- **Mithril bootstrap:** Node operators can now bootstrap a Dingo node from a Mithril snapshot and have the ledger state imported automatically (see “Fast Bootstrapping with Mithril” in `README.md`).
+- **Built-in HTTP APIs:** You can run Dingo with built-in, configurable HTTP APIs for common ecosystem compatibility.
+- **Block production:** Block production is now supported with Praos leader election and keystore-backed key management.
+- **Lifecycle events:** The node now emits richer on-chain lifecycle events that applications can subscribe to.
+- **Conway governance metadata:** Governance and Conway-era features are now available in the on-chain metadata pipeline.
+- **Leios mode:** A new “leios” mode is available for early experimentation with Leios protocols.
+- **Stake snapshots:** Stake snapshots and stake distribution are now available with persistence and querying.
+
+### 💪 Improvements
+
+- **Faster catch-up validation:** Syncing is now faster and safer by reducing unnecessary validation during initial catch-up.
+- **Tiered storage and caching:** Block and transaction storage can now be tuned for performance and cost with tiered storage and caching options.
+- **Rollback and resync:** Rollback and resync behavior is more robust under forks and stalled peers.
+- **Peer management:** Network and peer management now scales more predictably under load.
+- **Mempool resilience:** Transaction processing is more resilient and configurable under pressure.
+- **Observability:** Observability has been expanded across sync, forging, and storage.
+- **Time and nonce handling:** Epoch, slot, and nonce handling better matches Cardano semantics and edge cases.
+- **Docs:** Developer and operator documentation has been significantly expanded.
+
+### 🔧 Fixes
+
+- **Chainsync stability:** Chainsync is more reliable around header/block fetching and coordination.
+- **Concurrency safety:** Several concurrency and event-delivery deadlocks and goroutine leak risks have been eliminated.
+- **Security hardening:** Security hardening has been added for configuration, filesystem usage, and key material.
+- **Protocol validation:** Cryptographic and protocol-validation correctness has been tightened across eras.
+- **Object-store key encoding:** Storage key encoding issues in object stores have been resolved.
+
+### 📋 What You Need to Know
+
+- **Event consumers:** If you rely on event type strings, update consumers to match the renamed event type strings.
+- **API storage backfill:** If you enable API storage or new tiered storage modes, run a metadata backfill so queries return complete results.
+- **Forging setup:** If you enable forging, double-check VRF/KES/OpCert key paths and permissions first.
+
+### 🙏 Thank You
+
+Thank you for trying!
+
+---

package/{devnet.sh → devmode.sh}

@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 
-# Copyright 2025 Blink Labs Software
+# Copyright 2026 Blink Labs Software
 #
 # Licensed under the Apache License, Version 2.0 (the "License");
 # you may not use this file except in compliance with the License.
@@ -21,11 +21,11 @@ export CARDANO_DEV_MODE=true
 
 DEBUG=${DEBUG:-false}
 
-conf=$(dirname $CARDANO_CONFIG)
+conf="$(dirname "$CARDANO_CONFIG")"
 now=$(date -u +%s)
-echo setting start time in $conf to $now
-sed -i -e "s/startTime\": .*,/startTime\": $now,/" $conf/byron-genesis.json
-sed -i -e "s/systemStart\": .*,/systemStart\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ --date=@$now)\",/" $conf/shelley-genesis.json
+echo "setting start time in $conf to $now"
+sed -i -e "s/startTime\": .*,/startTime\": $now,/" "$conf/byron-genesis.json"
+sed -i -e "s/systemStart\": .*,/systemStart\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ --date=@$now)\",/" "$conf/shelley-genesis.json"
 
 echo resetting .devnet
 rm -rf .devnet/*

package/dingo.yaml.example

@@ -33,6 +33,8 @@ database:
       # Path prefix within the bucket
       prefix: ""
     s3:
+      # AWS Endpoint
+      endpoint: ""
       # AWS S3 bucket name
       bucket: ""
       # AWS region
@@ -46,12 +48,50 @@ database:
 
   # Metadata storage plugin configuration
   metadata:
-    # Plugin to use for metadata storage (sqlite)
+    # Plugin to use for metadata storage (sqlite, postgres, mysql)
     plugin: "sqlite"
     # Configuration options for each plugin
     sqlite:
-      # Data directory for SQLite database file
+      # Path to SQLite database file
       data-dir: ".dingo/metadata.db"
+    postgres:
+      # NOTE: These are example values for local development only.
+      # Do not use these credentials in production environments.
+      # Postgres host
+      host: "localhost"
+      # Postgres port
+      port: 5432
+      # Postgres user
+      user: "postgres"
+      # Postgres password (required - no default)
+      password: ""
+      # Postgres database name
+      database: "postgres"
+      # Postgres sslmode
+      ssl-mode: "disable"
+      # Postgres TimeZone
+      timezone: "UTC"
+      # Full Postgres DSN (overrides other options when set)
+      dsn: ""
+    mysql:
+      # NOTE: These are example values for local development only.
+      # Do not use these credentials in production environments.
+      # MySQL host
+      host: "localhost"
+      # MySQL port
+      port: 3306
+      # MySQL user
+      user: "root"
+      # MySQL password (required - no default)
+      password: ""
+      # MySQL database name
+      database: "mysql"
+      # MySQL TLS mode (mapped to tls= in DSN)
+      ssl-mode: ""
+      # MySQL time zone location
+      timezone: "UTC"
+      # Full MySQL DSN (overrides other options when set)
+      dsn: ""
 
 # Path to the UNIX domain socket file used by the server
 socketPath: "dingo.socket"
@@ -86,8 +126,64 @@ privatePort: 3002
 # Can be overridden with the port environment variable
 relayPort: 3001
 
-# TCP port to bind for listening for UTxO RPC
-utxorpcPort: 9090
+# Storage mode controls how much data is persisted.
+# - "core": Only consensus data (UTxOs, certs, pools, pparams). Suitable for
+#   block producers and relay nodes with no APIs enabled.
+# - "api": Core data plus full transaction metadata (witnesses, scripts, datums,
+#   redeemers). Required when any API is enabled.
+# APIs will refuse to start if storage mode is not "api".
+#
+# Can be overridden with DINGO_STORAGE_MODE
+storageMode: "core"
+
+# API ports (0 = disabled, default)
+# All APIs require storageMode: "api"
+#
+# UTxO RPC gRPC API port
+# Can be overridden with DINGO_UTXORPC_PORT
+utxorpcPort: 0
+# Blockfrost-compatible REST API port
+# Can be overridden with DINGO_BLOCKFROST_PORT
+blockfrostPort: 0
+# Mesh (Coinbase Rosetta) REST API port
+# Can be overridden with DINGO_MESH_PORT
+meshPort: 0
+
+# base url of bark archive server
+barkBaseUrl: ""
+
+# number of slots from tip within which blocks
+# will not be found in the bark archive
+barkSecurityWindow: 10000
+
+# TCP port bind for listening for bark RPC calls
+barkPort: 0
+
+# ---
+# Deployment pattern examples (uncomment one block):
+#
+# Relay node (core storage, no APIs):
+#   storageMode: "core"
+#   blockProducer: false
+#
+# Data node (API storage, one or more API ports enabled):
+#   storageMode: "api"
+#   utxorpcPort: 9090
+#   blockfrostPort: 3100
+#
+# Validator / block producer (core storage, no APIs):
+#   storageMode: "core"
+#   blockProducer: true
+#   shelleyVrfKey: "/keys/vrf.skey"
+#   shelleyKesKey: "/keys/kes.skey"
+#   shelleyOperationalCertificate: "/keys/opcert.cert"
+#   # Optional forging tolerances (0 = defaults)
+#   forgeSyncToleranceSlots: 0
+#   forgeStaleGapThresholdSlots: 0
+#
+# Dev mode (isolated, forge blocks, no outbound):
+#   runMode: "dev"
+# ---
 
 # Ignore prior chain history and start from current tip (default: false)
 # This is experimental and may break — use with caution
@@ -98,9 +194,91 @@ intersectTip: false
 # Default: 1048576 (1 MB)
 mempoolCapacity: 1048576
 
-# Enable development mode which prevents outbound connections
-# Default: false
-devMode: false
+# Forging tolerances (0 = defaults)
+# forgeSyncToleranceSlots controls how far the local chain can lag the upstream
+# tip before forging is skipped. forgeStaleGapThresholdSlots controls when to
+# log an error if the chain tip is far ahead of the slot clock.
+forgeSyncToleranceSlots: 0
+forgeStaleGapThresholdSlots: 0
+
+# Operational mode: "serve" (default), "load", or "dev"
+# - serve: Full node with network connectivity (default)
+# - load: Batch import from ImmutableDB (requires immutableDbPath)
+# - dev: Development mode (forge blocks, disable outbound, skip topology)
+# Note: CLI commands (serve, load) take priority over this setting
+#
+# Can be overridden with the DINGO_RUN_MODE environment variable
+runMode: "serve"
+
+# Path to ImmutableDB for batch import (used when runMode is "load")
+# Can also be provided as argument to 'dingo load' command
+#
+# Can be overridden with the DINGO_IMMUTABLE_DB_PATH environment variable
+immutableDbPath: ""
 
 # Validate historical blocks during ledger processing (default: false)
 validateHistorical: false
+
+# Peer targets - target number of peers in each state
+# These are goals the system works toward, not hard limits.
+# Use 0 for default values, -1 for unlimited
+# Default: known=150, established=50, active=20
+#
+# Target number of known (cold) peers
+targetNumberOfKnownPeers: 0
+# Target number of established (warm) peers
+targetNumberOfEstablishedPeers: 0
+# Target number of active (hot) peers
+targetNumberOfActivePeers: 0
+
+# Per-source quotas for active peers
+# These specify how active peer slots are distributed by source.
+# Use 0 for default values.
+# Default: topology=3, gossip=12, ledger=5
+#
+# Active peer slots for topology sources (local + public roots)
+activePeersTopologyQuota: 0
+# Active peer slots for gossip sources
+activePeersGossipQuota: 0
+# Active peer slots for ledger sources
+activePeersLedgerQuota: 0
+
+# Cache configuration for tiered CBOR cache system
+# This controls the in-memory caching of UTxO and transaction CBOR data
+cache:
+  # Number of entries in the hot UTxO cache (LFU eviction)
+  # Default: 50000
+  hotUtxoEntries: 50000
+  # Number of entries in the hot transaction cache (LFU eviction)
+  # Default: 10000
+  hotTxEntries: 10000
+  # Maximum memory in bytes for hot transaction cache
+  # Default: 268435456 (256 MB)
+  hotTxMaxBytes: 268435456
+  # Number of blocks to keep in the block LRU cache
+  # Default: 500
+  blockLruEntries: 500
+  # Number of recent blocks to warm up on startup
+  # Default: 1000
+  warmupBlocks: 1000
+  # Wait for cache warmup to complete before serving requests
+  # Default: true
+  warmupSync: true
+
+# Mithril snapshot bootstrap configuration
+# Use 'dingo mithril sync' or 'dingo sync --mithril' to bootstrap from a snapshot
+mithril:
+  # Enable Mithril integration (default: true)
+  enabled: true
+  # Override aggregator URL (auto-detected from network if empty)
+  # Supported networks: mainnet, preprod, preview
+  aggregatorUrl: ""
+  # Directory for downloading snapshot archives
+  # If empty, a randomized temporary directory is created automatically
+  # downloadDir: ""
+  # Remove temporary files after loading completes
+  # Default: true
+  cleanupAfterLoad: true
+  # Verify the Mithril certificate chain from snapshot back to genesis
+  # Default: true
+  verifyCertificates: true

package/docker-compose.yml

@@ -0,0 +1,51 @@
+# Dingo Cardano Node - Docker Compose Configuration
+#
+# Usage:
+#   docker compose up -d                        # Start with defaults (preview network)
+#   CARDANO_NETWORK=mainnet docker compose up -d # Start on mainnet
+#
+# With Mithril snapshot bootstrap (first run only):
+#   RESTORE_SNAPSHOT=1 docker compose up -d
+
+services:
+  # --------------------------------------------------------------------------
+  # Basic relay node
+  # --------------------------------------------------------------------------
+  dingo:
+    build:
+      context: .
+      dockerfile: Dockerfile
+    image: ghcr.io/blinklabs-io/dingo:latest
+    restart: unless-stopped
+    environment:
+      - CARDANO_NETWORK=${CARDANO_NETWORK:-preview}
+      - CARDANO_DATABASE_PATH=/data/db
+      - DINGO_SOCKET_PATH=/ipc/dingo.socket
+      # Uncomment to enable debug logging
+      # - DINGO_DEBUG=1
+      # Uncomment to bootstrap from Mithril snapshot on first run
+      # - RESTORE_SNAPSHOT=1
+    ports:
+      # Ouroboros Node-to-Node (relay port)
+      - "3001:3001"
+      # Prometheus metrics (localhost only by default)
+      - "127.0.0.1:12798:12798"
+      # UTxO RPC (gRPC, localhost only by default)
+      - "127.0.0.1:9090:9090"
+    volumes:
+      # Persistent database storage
+      - dingo-data:/data/db
+      # Unix socket for cardano-cli and other NtC clients
+      - dingo-ipc:/ipc
+    healthcheck:
+      test: ["CMD", "wget", "-qO-", "http://127.0.0.1:12798/metrics"]
+      interval: 30s
+      timeout: 5s
+      start_period: 60s
+      retries: 3
+
+volumes:
+  dingo-data:
+    driver: local
+  dingo-ipc:
+    driver: local

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blinklabs/dingo",
-  "version": "0.20.0",
+  "version": "0.23.0",
   "description": "Dingo is a Cardano blockchain data node",
   "main": "index.js",
   "bin": {

package/PLUGIN_DEVELOPMENT.md

@@ -1,306 +0,0 @@
-# Plugin Development Guide
-
-This guide explains how to develop plugins for Dingo's storage system.
-
-## Overview
-
-Dingo supports pluggable storage backends through a registration-based plugin system. Plugins can extend the system with new blob storage (blocks, transactions) and metadata storage (indexes, state) implementations.
-
-## Plugin Types
-
-### Blob Storage Plugins
-Store blockchain data (blocks, transactions, etc.). Examples:
-- `badger` - Local BadgerDB key-value store
-- `gcs` - Google Cloud Storage
-- `s3` - AWS S3
-
-#### Iterator lifetime note
-Blob plugins expose iterators via `NewIterator(txn, opts)`. Items returned by the
-iterator's `Item()` must only be accessed while the transaction used to create
-the iterator is still active — implementations may validate transaction state at
-access time and will return errors if the transaction has been committed or
-rolled back. See `database/types/types.go` `BlobIterator` for details.
-
-### Metadata Storage Plugins
-Store metadata and indexes. Examples:
-- `sqlite` - SQLite relational database
-
-## Plugin Interface
-
-All plugins must implement the `plugin.Plugin` interface:
-
-```go
-type Plugin interface {
-    Start() error
-    Stop() error
-}
-```
-
-## Plugin Registration
-
-Plugins register themselves during package initialization using the `plugin.Register()` function:
-
-```go
-func init() {
-    plugin.Register(plugin.PluginEntry{
-        Type:               plugin.PluginTypeBlob, // or PluginTypeMetadata
-        Name:               "myplugin",
-        Description:        "My custom storage plugin",
-        NewFromOptionsFunc: NewFromCmdlineOptions,
-        Options: []plugin.PluginOption{
-            // Plugin-specific options
-        },
-    })
-}
-```
-
-## Plugin Options
-
-Plugins define configuration options using the `PluginOption` struct:
-
-```go
-plugin.PluginOption{
-    Name:         "data-dir",           // Option name
-    Type:         plugin.PluginOptionTypeString, // Data type
-    Description:  "Data directory path", // Help text
-    DefaultValue: "/tmp/data",         // Default value
-    Dest:         &cmdlineOptions.dataDir, // Destination variable
-}
-```
-
-Supported option types:
-- `PluginOptionTypeString`
-- `PluginOptionTypeBool`
-- `PluginOptionTypeInt`
-- `PluginOptionTypeUint`
-
-## Environment Variables
-
-Plugins automatically support environment variables with the pattern:
-`DINGO_DATABASE_{TYPE}_{PLUGIN}_{OPTION}`
-
-Examples:
-- `DINGO_DATABASE_BLOB_BADGER_DATA_DIR=/data`
-- `DINGO_DATABASE_METADATA_SQLITE_DATA_DIR=/metadata.db`
-
-## YAML Configuration
-
-Plugins can be configured in `dingo.yaml`:
-
-```yaml
-database:
-  blob:
-    plugin: "myplugin"
-    myplugin:
-      option1: "value1"
-      option2: 42
-  metadata:
-    plugin: "sqlite"
-    sqlite:
-      data-dir: "/data/metadata.db"
-```
-
-## Configuration Precedence
-
-1. Command-line flags (highest priority)
-2. Environment variables
-3. YAML configuration
-4. Default values (lowest priority)
-
-## Command Line Options
-
-Plugins support command-line flags with the pattern:
-`--{type}-{plugin}-{option}`
-
-Examples:
-- `--blob-badger-data-dir /data`
-- `--metadata-sqlite-data-dir /metadata.db`
-
-## Plugin Development Steps
-
-### 1. Create Plugin Structure
-
-```text
-database/plugin/{type}/{name}/
-├── plugin.go      # Registration and options
-├── options.go     # Option functions
-├── database.go    # Core implementation
-└── options_test.go # Unit tests
-```
-
-### 2. Implement Core Plugin
-
-Create the main plugin struct that implements `plugin.Plugin`:
-
-```go
-type MyPlugin struct {
-    // Fields
-}
-
-func (p *MyPlugin) Start() error {
-    // Initialize resources
-    return nil
-}
-
-func (p *MyPlugin) Stop() error {
-    // Clean up resources
-    return nil
-}
-```
-
-### 3. Define Options
-
-Create option functions following the pattern:
-
-```go
-func WithOptionName(value Type) OptionFunc {
-    return func(p *MyPlugin) {
-        p.field = value
-    }
-}
-```
-
-### 4. Implement Constructors
-
-Provide both options-based and legacy constructors:
-
-```go
-func NewWithOptions(opts ...OptionFunc) (*MyPlugin, error) {
-    p := &MyPlugin{}
-    for _, opt := range opts {
-        opt(p)
-    }
-    return p, nil
-}
-
-func New(legacyParam1, legacyParam2) (*MyPlugin, error) {
-    // For backward compatibility
-    return NewWithOptions(
-        WithOption1(legacyParam1),
-        WithOption2(legacyParam2),
-    )
-}
-```
-
-### 5. Register Plugin
-
-In `plugin.go`, register during initialization:
-
-```go
-var cmdlineOptions struct {
-    option1 string
-    option2 int
-}
-
-func init() {
-    plugin.Register(plugin.PluginEntry{
-        Type: plugin.PluginTypeBlob,
-        Name: "myplugin",
-        Description: "My custom plugin",
-        NewFromOptionsFunc: NewFromCmdlineOptions,
-        Options: []plugin.PluginOption{
-            {
-                Name: "option1",
-                Type: plugin.PluginOptionTypeString,
-                Description: "First option",
-                DefaultValue: "default",
-                Dest: &cmdlineOptions.option1,
-            },
-            // More options...
-        },
-    })
-}
-
-func NewFromCmdlineOptions() plugin.Plugin {
-    p, err := NewWithOptions(
-        WithOption1(cmdlineOptions.option1),
-        WithOption2(cmdlineOptions.option2),
-    )
-    if err != nil {
-        panic(err)
-    }
-    return p
-}
-```
-
-### 6. Add Tests
-
-Create comprehensive tests:
-
-```go
-func TestOptions(t *testing.T) {
-    // Test option functions
-}
-
-func TestLifecycle(t *testing.T) {
-    p, err := NewWithOptions(WithOption1("test"))
-    // Test Start/Stop
-}
-```
-
-### 7. Update Imports
-
-Add your plugin to the import list in the appropriate store file:
-- `database/plugin/blob/blob.go` for blob plugins
-- `database/plugin/metadata/metadata.go` for metadata plugins
-
-## Example: Complete Plugin
-
-See the existing plugins for complete examples:
-- `database/plugin/blob/badger/` - BadgerDB implementation
-- `database/plugin/metadata/sqlite/` - SQLite implementation
-- `database/plugin/blob/gcs/` - Google Cloud Storage implementation
-- `database/plugin/blob/aws/` - AWS S3 implementation
-
-## Best Practices
-
-1. **Error Handling**: Always return descriptive errors
-2. **Resource Management**: Properly implement Start/Stop for resource lifecycle
-3. **Thread Safety**: Ensure plugins are safe for concurrent use
-4. **Configuration Validation**: Validate configuration during construction
-5. **Backward Compatibility**: Maintain compatibility with existing deployments
-6. **Documentation**: Document all options and their effects
-7. **Testing**: Provide comprehensive unit and integration tests
-
-## Testing Your Plugin
-
-### Unit Tests
-Test individual components and option functions.
-
-### Integration Tests
-Test the complete plugin lifecycle and interaction with the plugin system.
-
-### CLI Testing
-Use the CLI to test plugin listing and selection:
-
-```bash
-./dingo --blob list
-./dingo --metadata list
-```
-
-### Configuration Testing
-Test environment variables and YAML configuration:
-
-```bash
-DINGO_DATABASE_BLOB_MYPLUGIN_OPTION1=value ./dingo --blob myplugin
-```
-
-## Programmatic Option Overrides (for tests)
-
-When writing tests or programmatically constructing database instances you can override plugin options
-without importing plugin implementation packages directly by using the plugin registry helper:
-
-```go
-// Set data-dir for the blob plugin to a per-test temp directory
-plugin.SetPluginOption(plugin.PluginTypeBlob, "badger", "data-dir", t.TempDir())
-
-// Set data-dir for the metadata plugin
-plugin.SetPluginOption(plugin.PluginTypeMetadata, "sqlite", "data-dir", t.TempDir())
-```
-
-The helper sets the plugin option's destination variable in the registry before plugin instantiation.
-If the requested option is not defined by the targeted plugin the call is non-fatal and returns nil,
-allowing tests to run regardless of which plugin implementation is selected.
-
-Using `t.TempDir()` guarantees each test uses its own on-disk path and prevents concurrent tests from
-colliding on shared directories (for example the default `.dingo` Badger directory).