Skip to content

feat: rename iii-database to database#169

Merged
sergiofilhowz merged 2 commits into
mainfrom
feat/rename-database
May 20, 2026
Merged

feat: rename iii-database to database#169
sergiofilhowz merged 2 commits into
mainfrom
feat/rename-database

Conversation

@sergiofilhowz
Copy link
Copy Markdown
Contributor

@sergiofilhowz sergiofilhowz commented May 20, 2026

Summary by CodeRabbit

  • New Features

    • Added validation to prevent transaction control statements (e.g., COMMIT, ROLLBACK) from being executed within active transactions.
  • Bug Fixes

    • Improved transaction failure response to correctly report which statement failed.
  • Chores

    • Renamed worker from iii-database to database; all API functions and triggers now use the database:: namespace.

Review Change Stack

@vercel
Copy link
Copy Markdown

vercel Bot commented May 20, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
workers Ready Ready Preview, Comment May 20, 2026 2:50pm

Request Review

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented May 20, 2026

Warning

Rate limit exceeded

@sergiofilhowz has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 53 minutes and 12 seconds before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 2bacb5c1-2e11-4c3a-b108-0b8706d95940

📥 Commits

Reviewing files that changed from the base of the PR and between 19bf83d and 005d7df.

⛔ Files ignored due to path filters (1)
  • database/Cargo.lock is excluded by !**/*.lock
📒 Files selected for processing (3)
  • database/src/main.rs
  • database/tests/integration.rs
  • database/tests/value_coercion.rs
📝 Walkthrough

Walkthrough

This PR comprehensively renames the iii-database worker to database across the codebase while introducing transaction handler improvements. The rename affects build configuration, RPC registration, handlers, E2E tests, CI workflows, and documentation. Additionally, transaction failure semantics are refined to conditionally set failed_index only for driver errors with statement indices, and transaction_query validation is added to guard against transaction-control SQL.

Changes

Worker Renaming and API Updates

Layer / File(s) Summary
Worker manifest and build configuration
database/Cargo.toml, database/iii.worker.yaml, database/src/lib.rs, database/src/main.rs
Package crate name, binary target, worker manifest name/bin, and worker_name() constant updated from iii-database to database.
RPC function and trigger registration
database/src/main.rs, database/src/handlers/...
All registered function IDs (query, execute, prepare, run, transaction, interactive transaction, row-change trigger) updated from iii-database::* to database::*; handler module doc comments aligned with new namespace.
Transaction handler failure semantics and error serialization
database/src/handlers/transaction.rs
Introduced failed_index_of helper to conditionally populate failed_index only for driver errors with statement indices; serialize error on failure with JSON fallback; added unit/integration tests for success/rollback paths and wire-format invariants.
Interactive transaction query validation and handler
database/src/handlers/transaction_query.rs
New handler validates non-empty SQL, rejects transaction-control statements (including comment-prefixed forms) with INVALID_PARAM, parses parameters, dispatches to pinned driver connection, and includes comprehensive async test coverage.
E2E test harness framework and runner mode
database/tests/e2e/workers/harness/src/runner.ts
Refactored to introduce RunnerMode type controlling full/bypass-only execution, wire mode through runAll(), update database readiness probe to database::query, and generate reports including mode metadata.
E2E test case updates to database namespace
database/tests/e2e/workers/harness/src/cases-*.ts, database/tests/e2e/workers/harness/src/test.ts
All test case files updated to call database::* RPC functions instead of iii-database::* while preserving all assertions; new test.ts harness added for users table operations.
Integration tests and documentation updates
database/tests/integration.rs, database/README.md, database/skills/*, shell/tests/e2e/README.md
Updated test assertions and documentation to reference database::* API surface; skills index added for database worker with engine/driver/API description.
CI workflows and E2E configuration
.github/workflows/*, database/tests/e2e/config.yaml, database/tests/e2e/run-tests.sh, database/tests/e2e/workers/harness/package.json
GitHub Actions workflows, test configuration, and harness package name updated to target database instead of iii-database.
Storage module reference updates
storage/src/error.rs, storage/src/handlers/mod.rs, storage/src/triggers/dispatcher.rs, storage/tests/e2e/*
Documentation comments and test configuration references updated to database instead of iii-database; .gitignore updated for new harness path.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs

  • iii-hq/workers#64: Transaction handler failure semantics and failed_index population logic.
  • iii-hq/workers#165: Interactive transaction query validation and transaction-control SQL guarding.

Suggested reviewers

  • andersonleal
  • ytallo

Poem

🐰 From iii-database we hop away,
To database in every way—
Handlers renamed, tests aligned,
Transaction guards are well-designed,
A cleaner name, a clearer path,
Boing! 🎉

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The pull request title 'feat: rename iii-database to database' clearly and directly describes the primary change throughout the entire changeset, which systematically renames all references from 'iii-database' to 'database' across configuration files, source code, documentation, and tests.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feat/rename-database

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 20, 2026

skill-check — worker

1 verified, 10 skipped (no docs/).

1 error across the verified workers.

File Approximate line Severity Violation
shell/docs/leaves/kill.md ~7 error [Terminology.SlopMarketing] Avoid marketing/anthropomorphic phrasing 'Reaping'. Use concrete, technical language. (error)

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 4

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
database/src/handlers/transaction_query.rs (1)

36-43: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Use InvalidParam for empty SQL instead of DriverError.

This is handler-level input validation, so returning DriverError misclassifies client input as backend failure. Please return DbError::InvalidParam (index/field for sql) to keep error semantics consistent with the transaction-control guard path.

Suggested diff
-    if req.sql.trim().is_empty() {
-        return Err(err_to_str(DbError::DriverError {
-            driver: "(tx)".into(),
-            code: None,
-            message: "empty SQL".into(),
-            failed_index: None,
-        }));
-    }
+    if req.sql.trim().is_empty() {
+        return Err(err_to_str(DbError::InvalidParam {
+            index: 0,
+            reason: "empty SQL".into(),
+        }));
+    }
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@database/src/handlers/transaction_query.rs` around lines 36 - 43, Replace the
current DbError::DriverError return for empty SQL in transaction_query.rs with
DbError::InvalidParam to reflect client input validation: when
req.sql.trim().is_empty() return Err(err_to_str(DbError::InvalidParam { index:
Some("sql".into()), field: Some("sql".into()), message: "empty SQL".into() }));
locate the empty-SQL guard in the transaction SQL handler (the block that checks
req.sql.trim().is_empty()) and update the error variant and payload accordingly
so the handler-level validation matches the transaction-control guard semantics.
🧹 Nitpick comments (1)
database/tests/e2e/workers/harness/src/test.ts (1)

3-17: ⚡ Quick win

test.ts is not currently wired into the harness execution; consider removing or integrating it as a proper test case.

test.ts exists as an orphaned file and is not imported by any case file, npm script, or executed as part of the harness. If this is intended as a manual example or future test case, the SQL portability concerns are valid: INTEGER PRIMARY KEY is SQLite-specific (ROWID aliasing), and bare ? placeholders without explicit column mapping could have portability issues when integrated. If the file is to remain dormant, no action is needed. If it is to become an active test, apply the proposed fixes for multi-driver compatibility (use INT PRIMARY KEY, explicitly list columns in INSERT, and add result assertions).

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@database/tests/e2e/workers/harness/src/test.ts` around lines 3 - 17, test.ts
is an orphaned harness file; either delete it or wire it into the test harness
(import it from a case file or add an npm script) and make its SQL portable and
assertive: replace SQLite-specific "CREATE TABLE IF NOT EXISTS users (id INTEGER
PRIMARY KEY, ...)" with a portable "INT PRIMARY KEY" form, update the INSERT to
explicitly list columns and use explicit placeholders per value (e.g., INSERT
INTO users (email) VALUES (?), (?) → use one placeholder per value and matching
params or convert to two separate rows with matching params), ensure
call('database::execute') and call('database::query') are used with matching
params counts, and add assertions on the returned rows from
call('database::query') to validate inserted data before enabling this file in
the harness.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/database-e2e.yml:
- Around line 36-41: Replace the mutable action ref "uses:
actions/setup-node@v4" with a pinned commit SHA ref (e.g., "uses:
actions/setup-node@<commit-SHA>") to satisfy the unpinned-uses policy; update
the line that contains actions/setup-node@v4 in the workflow to the chosen
commit SHA and repeat the same pinning for other workflow steps that use mutable
tags to ensure all GitHub Action refs are pinned.

In `@database/Cargo.toml`:
- Line 4: The package rename removed the explicit library crate name so imports
like iii_database:: now fail; add an explicit [lib] section in Cargo.toml
setting name = "iii_database" (so the library crate keeps the old symbol) to
restore those iii_database:: imports, and ensure src/lib.rs exists as the
library entrypoint referenced by that lib definition.

In `@database/skills/iii-database/transaction.md`:
- Line 164: The sentence about `database::query` is misleading; update the docs
to state that `database::query` is a separate read-only API and should not be
treated as part of the `database::transaction` surface; inside
`database::transaction` callers must include raw SELECT statements in the
`statements` array and expect result rows to follow the transaction response
shape (not the `database::query` envelope), and if you only need row counts use
the transaction's `affected_rows`-equivalent handling rather than referring to
`database::query`.

In `@database/tests/e2e/workers/harness/src/runner.ts`:
- Line 105: The test harness currently calls waitForDatabaseWorker only for
drivers[0], so later drivers may not be ready; update runner.ts to wait for
every driver in the drivers array by iterating over drivers and awaiting
waitForDatabaseWorker(driver) for each (either sequentially with for...of await
or concurrently with Promise.all), referencing the existing
waitForDatabaseWorker function and the drivers variable so every driver is
readiness-checked before tests run.

---

Outside diff comments:
In `@database/src/handlers/transaction_query.rs`:
- Around line 36-43: Replace the current DbError::DriverError return for empty
SQL in transaction_query.rs with DbError::InvalidParam to reflect client input
validation: when req.sql.trim().is_empty() return
Err(err_to_str(DbError::InvalidParam { index: Some("sql".into()), field:
Some("sql".into()), message: "empty SQL".into() })); locate the empty-SQL guard
in the transaction SQL handler (the block that checks req.sql.trim().is_empty())
and update the error variant and payload accordingly so the handler-level
validation matches the transaction-control guard semantics.

---

Nitpick comments:
In `@database/tests/e2e/workers/harness/src/test.ts`:
- Around line 3-17: test.ts is an orphaned harness file; either delete it or
wire it into the test harness (import it from a case file or add an npm script)
and make its SQL portable and assertive: replace SQLite-specific "CREATE TABLE
IF NOT EXISTS users (id INTEGER PRIMARY KEY, ...)" with a portable "INT PRIMARY
KEY" form, update the INSERT to explicitly list columns and use explicit
placeholders per value (e.g., INSERT INTO users (email) VALUES (?), (?) → use
one placeholder per value and matching params or convert to two separate rows
with matching params), ensure call('database::execute') and
call('database::query') are used with matching params counts, and add assertions
on the returned rows from call('database::query') to validate inserted data
before enabling this file in the harness.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: e6d49e96-d9c8-42d3-8227-5edb1a608a59

📥 Commits

Reviewing files that changed from the base of the PR and between 610c0e0 and 19bf83d.

⛔ Files ignored due to path filters (2)
  • database/Cargo.lock is excluded by !**/*.lock
  • database/tests/e2e/workers/harness/package-lock.json is excluded by !**/package-lock.json
📒 Files selected for processing (81)
  • .github/workflows/create-tag.yml
  • .github/workflows/database-e2e.yml
  • .github/workflows/release.yml
  • .gitignore
  • README.md
  • database/.gitignore
  • database/Cargo.toml
  • database/README.md
  • database/config.yaml
  • database/config.yaml.example
  • database/iii.worker.yaml
  • database/skills/iii-database/execute.md
  • database/skills/iii-database/interactive-transaction.md
  • database/skills/iii-database/prepared-statements.md
  • database/skills/iii-database/query.md
  • database/skills/iii-database/transaction.md
  • database/skills/index.md
  • database/src/config.rs
  • database/src/driver/mod.rs
  • database/src/driver/mysql.rs
  • database/src/driver/postgres.rs
  • database/src/driver/sqlite.rs
  • database/src/error.rs
  • database/src/handle.rs
  • database/src/handlers/begin_transaction.rs
  • database/src/handlers/commit_transaction.rs
  • database/src/handlers/execute.rs
  • database/src/handlers/mod.rs
  • database/src/handlers/prepare.rs
  • database/src/handlers/query.rs
  • database/src/handlers/rollback_transaction.rs
  • database/src/handlers/run_statement.rs
  • database/src/handlers/transaction.rs
  • database/src/handlers/transaction_execute.rs
  • database/src/handlers/transaction_query.rs
  • database/src/handlers/tx_sql_guard.rs
  • database/src/lib.rs
  • database/src/main.rs
  • database/src/pool/mod.rs
  • database/src/pool/mysql.rs
  • database/src/pool/postgres.rs
  • database/src/pool/sqlite.rs
  • database/src/pool/tls.rs
  • database/src/transaction.rs
  • database/src/triggers/handler.rs
  • database/src/triggers/mod.rs
  • database/src/triggers/row_change.rs
  • database/src/value.rs
  • database/tests/e2e/.gitignore
  • database/tests/e2e/README.md
  • database/tests/e2e/config.yaml
  • database/tests/e2e/docker-compose.yml
  • database/tests/e2e/reports/.gitkeep
  • database/tests/e2e/run-tests.sh
  • database/tests/e2e/workers/harness/iii.worker.yaml
  • database/tests/e2e/workers/harness/package.json
  • database/tests/e2e/workers/harness/src/cases-boundary.ts
  • database/tests/e2e/workers/harness/src/cases-concurrency.ts
  • database/tests/e2e/workers/harness/src/cases-interactive-tx.ts
  • database/tests/e2e/workers/harness/src/cases-protocol.ts
  • database/tests/e2e/workers/harness/src/cases-row-change.ts
  • database/tests/e2e/workers/harness/src/cases-transaction.ts
  • database/tests/e2e/workers/harness/src/cases-tx-control-bypass.ts
  • database/tests/e2e/workers/harness/src/cases.ts
  • database/tests/e2e/workers/harness/src/dialect.test.ts
  • database/tests/e2e/workers/harness/src/dialect.ts
  • database/tests/e2e/workers/harness/src/runner.ts
  • database/tests/e2e/workers/harness/src/test.ts
  • database/tests/e2e/workers/harness/src/worker.ts
  • database/tests/e2e/workers/harness/tsconfig.json
  • database/tests/integration.rs
  • database/tests/value_coercion.rs
  • iii-database/skills/index.md
  • iii-database/tests/e2e/reports/.gitkeep
  • iii-database/tests/e2e/workers/harness/src/test.ts
  • shell/tests/e2e/README.md
  • storage/src/error.rs
  • storage/src/handlers/mod.rs
  • storage/src/triggers/dispatcher.rs
  • storage/tests/e2e/config.yaml
  • storage/tests/e2e/run-tests.sh
💤 Files with no reviewable changes (2)
  • iii-database/skills/index.md
  • iii-database/tests/e2e/workers/harness/src/test.ts

Comment on lines 36 to +41
- name: Install Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
cache-dependency-path: iii-database/tests/e2e/workers/harness/package-lock.json
cache-dependency-path: database/tests/e2e/workers/harness/package-lock.json
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

fd -e yml -e yaml .github/workflows | while read -r wf; do
  echo "== $wf =="
  rg -n '^\s*uses:\s*[^@\s]+@[^\s#]+' "$wf" \
    | rg -n '@(v[0-9]+(\.[0-9]+)?|main|master)$' || true
done

Repository: iii-hq/workers

Length of output: 432


🏁 Script executed:

# First, let's verify the specific file and line numbers
cat -n .github/workflows/database-e2e.yml | sed -n '30,45p'

Repository: iii-hq/workers

Length of output: 726


🏁 Script executed:

# Run the corrected command to find all tag/branch-pinned actions in workflows
fd . '.github/workflows' -e yml -e yaml | while read -r wf; do
  echo "== $wf =="
  rg -n '^\s*uses:\s*[^@\s]+@[^\s#]+' "$wf" \
    | rg '@(v[0-9]+(\.[0-9]+)?|main|master)$' || true
done

Repository: iii-hq/workers

Length of output: 1409


Pin GitHub Action refs to commit SHAs.

Line 37 uses actions/setup-node@v4 (mutable version tag), which violates strict workflow hardening practices and can fail unpinned-uses policy checks. Convert to a pinned commit SHA (e.g., actions/setup-node@1e21ff14b671a668ad81a1eac58d86bc5915f5a6).

Note: This pattern appears across multiple workflows—consider auditing all workflow files to pin GitHub Actions consistently.

🧰 Tools
🪛 zizmor (1.25.2)

[error] 37-37: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/database-e2e.yml around lines 36 - 41, Replace the mutable
action ref "uses: actions/setup-node@v4" with a pinned commit SHA ref (e.g.,
"uses: actions/setup-node@<commit-SHA>") to satisfy the unpinned-uses policy;
update the line that contains actions/setup-node@v4 in the workflow to the
chosen commit SHA and repeat the same pinning for other workflow steps that use
mutable tags to ensure all GitHub Action refs are pinned.

Comment thread database/Cargo.toml
- `iii-database::prepareStatement` + `iii-database::runStatement` — for repeating one parameterized statement many times; not a substitute for atomic multi-statement commit.
- [`database::beginTransaction` + `transactionQuery` / `transactionExecute` + `commitTransaction` / `rollbackTransaction`](iii://database/interactive-transaction) — **stateful interactive** transaction with a configurable timeout-driven auto-rollback. Use this surface when you need to take a decision in application code *between* statements (read-your-writes across round-trips). The batch handler on this page requires every statement up-front, so it can't carry that inter-statement logic.
- `database::execute` — single-statement variant; skips the BEGIN/COMMIT framing for one-shot writes.
- `database::query` — read-only; cannot be combined with writes inside this surface but is fine to mix into the `statements` array if you only need its rows for `affected_rows`-equivalent counts.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Clarify database::query guidance to avoid contradictory transaction semantics.

This line currently says database::query is outside this surface, but then suggests mixing it into statements with affected_rows-equivalent behavior. Inside database::transaction, callers should add SELECT SQL directly to statements, and result rows follow the transaction response shape (not database::query’s envelope).

✏️ Suggested doc fix
-- `database::query` — read-only; cannot be combined with writes inside this surface but is fine to mix into the `statements` array if you only need its rows for `affected_rows`-equivalent counts.
+- `database::query` — read-only standalone surface. Within `database::transaction`, include read SQL directly in `statements` when needed; results come back in the transaction `results` shape.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
- `database::query` — read-only; cannot be combined with writes inside this surface but is fine to mix into the `statements` array if you only need its rows for `affected_rows`-equivalent counts.
- `database::query` — read-only standalone surface. Within `database::transaction`, include read SQL directly in `statements` when needed; results come back in the transaction `results` shape.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@database/skills/iii-database/transaction.md` at line 164, The sentence about
`database::query` is misleading; update the docs to state that `database::query`
is a separate read-only API and should not be treated as part of the
`database::transaction` surface; inside `database::transaction` callers must
include raw SELECT statements in the `statements` array and expect result rows
to follow the transaction response shape (not the `database::query` envelope),
and if you only need row counts use the transaction's `affected_rows`-equivalent
handling rather than referring to `database::query`.

const drivers: DriverKey[] = this.opts.filterDriver ? [this.opts.filterDriver] : [...DRIVER_KEYS]
// Wait for the database worker to be reachable on the first driver before kicking off.
await this.waitForDatabaseWorker(drivers[0]);
await this.waitForDatabaseWorker(drivers[0])
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Wait for each driver, not only the first one.

Readiness is checked only for drivers[0], but tests execute against every driver. Later drivers can still race startup and fail/skip their suite spuriously.

Suggested fix
-    // Wait for the database worker to be reachable on the first driver before kicking off.
-    await this.waitForDatabaseWorker(drivers[0])
+    // Wait for each driver right before running its cases.
 
     const results: CaseResult[] = []
@@
     for (const driver of drivers) {
+      await this.waitForDatabaseWorker(driver)
       if (includeFullSuite) {
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
await this.waitForDatabaseWorker(drivers[0])
// Wait for each driver right before running its cases.
const results: CaseResult[] = []
for (const driver of drivers) {
await this.waitForDatabaseWorker(driver)
if (includeFullSuite) {
// ... rest of the code
}
}
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@database/tests/e2e/workers/harness/src/runner.ts` at line 105, The test
harness currently calls waitForDatabaseWorker only for drivers[0], so later
drivers may not be ready; update runner.ts to wait for every driver in the
drivers array by iterating over drivers and awaiting
waitForDatabaseWorker(driver) for each (either sequentially with for...of await
or concurrently with Promise.all), referencing the existing
waitForDatabaseWorker function and the drivers variable so every driver is
readiness-checked before tests run.

@sergiofilhowz sergiofilhowz merged commit e36426c into main May 20, 2026
17 of 19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant