Thank you for your interest in contributing to FoldDB! This document provides guidelines and instructions for contributing.
- Fork the repository
- Clone your fork:
git clone https://github.com/YOUR_USERNAME/fold_db.git - Create a feature branch:
git checkout -b feature/your-feature-name - Make your changes
- Run tests:
cargo test --lib - Submit a pull request
- Rust 1.70+ with Cargo
- Node.js 16+ (for frontend development)
- AWS credentials (optional, for cloud features)
Some test fixtures (e.g., tests/fixtures/tweets.js) are tracked with Git LFS. To download them:
git lfs install # one-time setup
git lfs pull # download LFS-tracked filesWithout this, those files will be small pointer files instead of actual data, and related tests will fail.
# Build without AWS features
cargo build
# Build with AWS backend support
cargo build --features aws-backend
# Run linter
cargo clippy
cargo clippy --features aws-backend# Run all library tests
cargo test --lib
# Run a specific test with output
cargo test test_name -- --nocapture
# Run frontend tests
cd src/server/static-react
npm test# Local mode with Sled storage + prod schema service (recommended)
./run.sh --local
# Local mode with dev schema service
./run.sh --local --dev
# Fully offline development (local storage + local schema service)
./run.sh --local --local-schema
# Local mode with fresh empty database
./run.sh --local --empty-db
# Cloud mode (requires AWS credentials)
./run.sh
# Show all options
./run.sh --helpThe script automatically kills any existing processes before starting.
- Follow standard Rust formatting (
cargo fmt) - Pass all clippy lints (
cargo clippy) - No silent failures - always propagate or handle errors explicitly
- Avoid unnecessary branching logic
- Use
SchemaErrorfor domain errors - Import crates in file headers, not inline
- Use
TODOcomments for incomplete implementations
- Run
npm run lintbefore committing - Use TypeScript strict mode
- Follow existing patterns for Redux slices and API clients
src/
├── fold_node/ # FoldNode — top-level orchestrator (DB + security + config)
│ └── node.rs # FoldNode struct, clone-friendly Arc wrapper
├── fold_db_core/ # Core database logic (FoldDb, schema manager)
│ └── fold_db.rs
├── schema/ # Schema system
│ ├── core.rs # SchemaManager — load, approve, query schemas
│ └── types/ # Schema, Field, Query, Mutation, Transform, KeyConfig
├── storage/ # Storage backends
│ ├── traits.rs # KvStore trait — unified async interface
│ ├── sled_store.rs # Local embedded storage
│ └── dynamo_store.rs # AWS DynamoDB backend (behind `aws-backend` feature)
├── handlers/ # Framework-agnostic request handlers
│ ├── mod.rs # Shared handler layer (used by HTTP server AND Lambda)
│ └── ingestion.rs # Ingestion-specific handlers
├── ingestion/ # AI-powered data ingestion pipeline
│ ├── ingestion_service/ # Main service (schema recommendation, mutation generation)
│ ├── anthropic_service.rs # Cloud LLM client (https://api.anthropic.com)
│ ├── ollama_service.rs # Local LLM client (http://127.0.0.1:11434)
│ ├── error.rs # IngestionError with LLM error classifiers
│ └── routes.rs # HTTP routes (Actix-web)
├── server/
│ ├── http_server.rs # Actix-web server setup and route registration
│ └── static-react/ # React frontend (Vite + TypeScript + Redux)
└── error.rs # Top-level FoldDbError
-
Handler pattern: Handlers in
src/handlers/take typed requests and return typed responses. They're shared between the HTTP server (http_server.rs) and AWS Lambda (exemem-infra/lambdas/). Keep handlers framework-agnostic — noactix_weborlambda_httptypes. -
KvStore trait: All storage operations go through the
KvStoretrait (src/storage/traits.rs). Local mode usesSledStore; cloud mode usesDynamoStore. Never call storage backends directly. -
Schema lifecycle: Schemas flow through
Pending->Approvedstates. New schemas are created via the schema service, loaded into the localSchemaManager, then approved. Mutations can only write to approved schemas.
Place tests in the same file using #[cfg(test)] mod tests. Run with:
cargo test --lib # All unit tests
cargo test --lib ingestion::error::tests # Specific module
cargo test test_name -- --nocapture # Single test with outputIntegration tests live in tests/. Use test://mock as the schema_service_url to avoid hitting the real schema service:
let config = FoldNodeConfig {
schema_service_url: "test://mock".to_string(),
// ...
};Test fixtures like tests/fixtures/tweets.js are stored in Git LFS. Run git lfs pull after cloning. Without this, fixture files will be pointer stubs and related tests will fail.
cd src/server/static-react
npm test # Run vitest once
npm run test:watch # Watch mode
npm run lint # ESLintFrontend tests use Vitest. Follow existing patterns in src/__tests__/ for component and Redux slice tests.
FoldDB uses feature-scoped logging. Set the log level with:
FOLD_LOG_LEVEL=debug ./run.sh --localAvailable levels: trace, debug, info (default), warn, error.
Logs are tagged by feature (e.g., [Ingestion], [HttpServer], [Schema]). To filter:
FOLD_LOG_LEVEL=debug ./run.sh --local 2>&1 | grep '\[Ingestion\]'| Symptom | Likely cause | Fix |
|---|---|---|
| "Schema not found" on mutation | Schema not approved | Call schema_manager.approve("name") |
| "Anthropic service not initialized" | Missing API key | Configure your Anthropic API key in Settings → AI Provider (or switch the provider to Ollama) |
| Frontend embed error at build | Missing dist/ |
cd src/server/static-react && npm ci && npm run build |
| Test fixture is 130 bytes | Git LFS pointer | git lfs pull |
# Check all schemas in the database
curl http://localhost:9001/api/schema/list | jq
# Inspect a specific schema
curl http://localhost:9001/api/schema/get/SCHEMA_NAME | jq
# Check ingestion service status
curl http://localhost:9001/api/ingestion/status | jq
# Watch ingestion progress
curl http://localhost:9001/api/ingestion/progress | jq- Ensure all tests pass locally
- Update documentation if needed
- Add tests for new functionality
- Keep PRs focused - one feature or fix per PR
- Write clear commit messages describing the "why" not just the "what"
- Reference any related issues in the PR description
Use clear, descriptive commit messages:
feat: add native index support for range queries
fix: resolve race condition in transform queue
docs: update API documentation for ingestion endpoints
refactor: simplify storage backend trait hierarchy
- Use GitHub Issues for bug reports and feature requests
- Search existing issues before creating a new one
- Provide reproduction steps for bugs
- Include relevant logs and error messages
Please read and follow our Code of Conduct.
Open a GitHub Discussion for questions about contributing or the codebase.