feat: database with configuration#194
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
More reviews will be available in 34 minutes and 52 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the 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 include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughThis pull request transitions the database worker from file-based configuration to runtime configuration management. The ChangesDatabase Configuration Architecture
🎯 4 (Complex) | ⏱️ ~75 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
skill-check — worker0 verified, 13 skipped (no docs/).
Three for three. Nicely done. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🤖 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 46-49: The CI step that runs the installer uses the flag "--next"
(see the "Install iii engine (next)" step and the curl ... | sh -s -- --next
invocation) which pulls a moving pre-release; replace the dynamic "--next" flag
with a pinned release tag string (e.g., "--version vX.Y.Z" or the specific
pre-release "--version vX.Y.Z-next.1" depending on desired stability) so the
workflow installs a reproducible engine version; update the step name
accordingly if needed.
In `@database/skills/SKILL.md`:
- Around line 94-95: The SKILL.md entry for database::row-change and the README
disagree about v1.0.0 behavior; decide whether v1.0.0 should (A) return
UNSUPPORTED from registerTrigger or (B) succeed on setup (slot/publication) but
stub streaming. Update the SKILL.md text around database::row-change and the
registerTrigger description to match the chosen contract, referencing the
registerTrigger symbol and the database::row-change capability so both docs
consistently state the same behavior (either explicit UNSUPPORTED return or
“setup succeeds, streaming stubbed”) and include any notes about pending
tokio-postgres replication API availability.
In `@database/src/config.rs`:
- Around line 12-15: This file fails rustfmt checks due to import ordering and
line-wrapping around long schema/test assertion lines; run rustfmt to reflow
imports and wrap long lines (e.g., the use statements like use
schemars::JsonSchema, use schemars::schema::Schema, use serde::{Deserialize,
Serialize}, use serde_json::{json, Value}) and the long blocks around the
schema/test assertions (also at the regions corresponding to lines 229-237 and
410-456) by running cargo fmt --all (or cargo fmt --all -- --check to verify)
and commit the formatted output.
In `@database/src/configuration.rs`:
- Around line 7-9: Run rustfmt on this module (configuration.rs) and reformat
the imports and wrapped function/signature lines so they comply with cargo fmt
--check; specifically tidy the use group containing III, IIIError,
RegisterFunction, RegisterTriggerInput, TriggerRequest and fix wrapping for the
affected function signatures and call sites (areas around the
RegisterFunction/RegisterTriggerInput/TriggerRequest usages and the long blocks
later in the file) so the import grouping and line wrapping conform to rustfmt
rules, then re-commit the formatted file.
In `@database/src/main.rs`:
- Around line 22-24: The multi-line use import for iii_sdk is failing rustfmt;
change the import to rustfmt-preferred grouping by placing the items inside a
single braced list (i.e., use iii_sdk::{register_worker, InitOptions,
RegisterFunction, RegisterTriggerType};) so that the symbols register_worker,
InitOptions, RegisterFunction, and RegisterTriggerType are formatted as a single
grouped import instead of the current broken multi-line form.
In `@database/tests/e2e/workers/harness/fixtures/database.schema.json`:
- Around line 152-173: The root JSON schema is missing a required declaration
for the "databases" property so an empty object {} can still validate; update
database.schema.json to add a root "required" array that includes "databases"
(so the existing "databases" definition with "minProperties":1 is enforced) —
locate the top-level schema object in database.schema.json and add "required":
["databases"] alongside the existing "properties" entry.
In `@database/tests/integration.rs`:
- Around line 42-45: The assertion block comparing
from_yaml.databases["primary"].driver and from_json.databases["primary"].driver
is failing rustfmt; reformat this assertion to comply with rustfmt (either
collapse to a single-line assert_eq! or let rustfmt reflow the multiline form)
and then run cargo fmt --all to apply the style changes; ensure the identifiers
from_yaml, from_json, databases, and driver remain unchanged so the assertion
logic is preserved.
🪄 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: f6390dcb-096b-4ade-96cc-e52fef6a97e7
📒 Files selected for processing (33)
.github/workflows/database-e2e.ymldatabase/README.mddatabase/config.yamldatabase/config.yaml.exampledatabase/skills/SKILL.mddatabase/skills/iii-database/execute.mddatabase/skills/iii-database/interactive-transaction.mddatabase/skills/iii-database/prepared-statements.mddatabase/skills/iii-database/query.mddatabase/skills/iii-database/transaction.mddatabase/skills/index.mddatabase/src/config.rsdatabase/src/configuration.rsdatabase/src/handlers/begin_transaction.rsdatabase/src/handlers/commit_transaction.rsdatabase/src/handlers/execute.rsdatabase/src/handlers/mod.rsdatabase/src/handlers/prepare.rsdatabase/src/handlers/query.rsdatabase/src/handlers/rollback_transaction.rsdatabase/src/handlers/run_statement.rsdatabase/src/handlers/transaction.rsdatabase/src/handlers/transaction_execute.rsdatabase/src/lib.rsdatabase/src/main.rsdatabase/tests/e2e/README.mddatabase/tests/e2e/config.yamldatabase/tests/e2e/run-tests.shdatabase/tests/e2e/workers/harness/fixtures/database.schema.jsondatabase/tests/e2e/workers/harness/package.jsondatabase/tests/e2e/workers/harness/src/database-config.tsdatabase/tests/e2e/workers/harness/src/seed-configuration.tsdatabase/tests/integration.rs
💤 Files with no reviewable changes (7)
- database/skills/iii-database/execute.md
- database/config.yaml
- database/skills/iii-database/query.md
- database/skills/iii-database/transaction.md
- database/skills/iii-database/prepared-statements.md
- database/skills/index.md
- database/skills/iii-database/interactive-transaction.md
| - name: Install iii engine (next) | ||
| run: | | ||
| curl -fsSL --retry 3 --retry-connrefused --retry-delay 5 \ | ||
| https://install.iii.dev/iii/main/install.sh | sh | ||
| https://install.iii.dev/iii/main/install.sh | sh -s -- --next |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What installation flags does https://install.iii.dev/iii/main/install.sh support for pinning a specific iii engine version, and what is the recommended CI strategy for reproducible installs (exact version vs channel)?
💡 Result:
The iii engine installer script (https://install.iii.dev/iii/main/install.sh) supports these installation “pinning” arguments: 1) Pin an exact engine version - Usage: sh -s -- v0.9.0 (the docs show passing the version argument as vX.Y.Z) [1] - Behavior: when a specific VERSION is requested, the installer rejects prerelease versions (it checks the GitHub release JSON’s prerelease field, and errors if prerelease == true) [2] 2) Install “latest stable” (channel behavior) - Default behavior (no -v / version argument): the script “installing latest version” [2] - Under the hood: for latest-version selection it probes GitHub’s /releases/latest first, and only accepts a tag that matches the expected prefix (iii/v*) and is non-draft/non-prerelease; if that fails, it falls back to listing releases and filtering by prerelease==false and tag_name prefix iii/v* [2] So, for pinning reproducibly, prefer exact version pinning (e.g., v0.9.0) over “channel/latest” resolution [1][2]. Recommended CI strategy for reproducible installs (exact version vs channel) - Recommended: pin an exact version (e.g., use -v vX.Y.Z / pass vX.Y.Z as the version argument) in CI, not the moving “latest”/channel behavior, because “latest” is resolved at install time by querying GitHub releases/latest and filtering [2]. - Additionally, do not use prerelease channels in CI: the engine installer explicitly rejects prereleases even when a specific version is requested (“version $VERSION is a prerelease — use a stable release”) [2]. If you want stronger reproducibility than “install a single binary version,” use the project’s lockfile workflow for registry-managed workers: commit iii.lock with config.yaml and replay with iii worker sync so CI/dev/deploy environments install/repair the same pinned set (and the sync step verifies binaries by SHA-256 before activation) [3].
Citations:
- 1: https://github.com/iii-hq/iii/blob/main/engine/README.md
- 2: iii-hq/iii@2d38cc2
- 3: https://iii.dev/docs/how-to/reproduce-worker-installs
🌐 Web query:
What does the iii engine installer script https://install.iii.dev/iii/main/install.sh interpret the --next flag as (prerelease/next channel vs something else), and how should CI handle it for reproducible installs?
💡 Result:
The --next flag in the iii engine installer script (https://install.iii.dev/iii/main/install.sh) directs the script to fetch and install the latest pre-release version of the iii engine [1]. Specifically, it triggers logic that queries GitHub releases for tags matching the -next. pattern (such as iii/v*-next.*) [1][2], rather than defaulting to the latest stable release [1][3]. How CI Should Handle It for Reproducible Installs: Because --next fetches the latest available pre-release dynamically, it is inherently non-deterministic and unsuitable for reproducible CI environments [1]. To ensure reproducibility in CI/CD pipelines, you should pin the engine to a specific version instead of using the --next flag [4][5]. 1. Pin to a Specific Version: Use the script's ability to accept a version argument directly. By providing a specific tag, you ensure the installer fetches a known, immutable release [4][5]. Example: curl -fsSL https://install.iii.dev/iii/main/install.sh | sh -s -- v0.12.0 2. Avoid --next in Production CI: The --next flag is intended for "work-in-progress" (WIP) testing and development environments where tracking the cutting edge is desired [1]. If you must test pre-release builds, pin to a specific pre-release tag (e.g., v0.12.0-next.1) rather than using the generic --next flag to avoid unexpected breaking changes between CI runs [1][2]. 3. Verify Dependencies: Ensure your CI environment validates the checksum or version of the installed binary to prevent supply chain drift [6][3]. Since the installer script itself can evolve [7][2], pinning the version and potentially caching the installer script or the downloaded binary are best practices for maintaining a locked environment [4].
Citations:
- 1: feat: add "next" pre-release channel for WIP testing iii#1426
- 2: fix(console/install.sh): accept iii/v* monorepo release tags iii#1660
- 3: fix: use /releases/latest in install.sh and fix no-jq prerelease bug iii#1363
- 4: https://github.com/iii-hq/iii/blob/main/engine/README.md
- 5: iii-hq/iii@2d38cc2
- 6: https://dev.to/gde/getting-started-with-antigravity-cli-183g
- 7: install.iii.dev script: tag-prefix filter rejects every stable release (
iii/v...notv...) iii#1652
Pin iii engine to a specific release in CI (avoid --next)
In .github/workflows/database-e2e.yml, --next installs the latest pre-release dynamically (e.g., matching *-next.*), making E2E runs non-reproducible and prone to unexpected breakage. Pin an exact stable engine version (e.g., vX.Y.Z), or if you need WIP, pin a specific pre-release tag (e.g., vX.Y.Z-next.1) instead of using --next.
🤖 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 46 - 49, The CI step that
runs the installer uses the flag "--next" (see the "Install iii engine (next)"
step and the curl ... | sh -s -- --next invocation) which pulls a moving
pre-release; replace the dynamic "--next" flag with a pinned release tag string
(e.g., "--version vX.Y.Z" or the specific pre-release "--version vX.Y.Z-next.1"
depending on desired stability) so the workflow installs a reproducible engine
version; update the step name accordingly if needed.
| - You need events today — v1.0.0 returns `UNSUPPORTED` on `registerTrigger` | ||
| pending an upstream `tokio-postgres` replication API release. |
There was a problem hiding this comment.
Conflicting database::row-change behavior description.
Line 94 states registerTrigger returns UNSUPPORTED, but the main README describes v1.0.0 as setup-only (slot/publication creation succeeds; streaming is stubbed). Please align both docs to one behavior contract.
🤖 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/SKILL.md` around lines 94 - 95, The SKILL.md entry for
database::row-change and the README disagree about v1.0.0 behavior; decide
whether v1.0.0 should (A) return UNSUPPORTED from registerTrigger or (B) succeed
on setup (slot/publication) but stub streaming. Update the SKILL.md text around
database::row-change and the registerTrigger description to match the chosen
contract, referencing the registerTrigger symbol and the database::row-change
capability so both docs consistently state the same behavior (either explicit
UNSUPPORTED return or “setup succeeds, streaming stubbed”) and include any notes
about pending tokio-postgres replication API availability.
1 participant
Summary by CodeRabbit
New Features
Documentation