feat(cli): add 'sorokeep tag' command to add/remove contract tags

[muffti123]

Summary

Adds a sorokeep tag command so tags can be added/removed on an already-watched contract without re-running watch (which would otherwise risk resetting other fields like poll_interval_seconds).

sorokeep tag add <contract-id> <tag>
sorokeep tag remove <contract-id> <tag>

Each invocation mutates the contract's tag list and prints the resulting full tag list for confirmation.

Changes

• src/db/repositories.ts
  • Added addContractTag(db, contractId, tag) and removeContractTag(db, contractId, tag).
  • They read the current tags value, mutate the set, and write it back, reusing the serialization format settled by the companion --tag filter issue: a comma-separated string with trimmed, exact-match values (an empty set is stored as NULL).
  • Both return the resulting tag list; both throw a clear Contract <id> is not registered. error for unregistered contracts.
• src/commands/tag.ts (new)
  • sorokeep tag add <contract-id> <tag> and sorokeep tag remove <contract-id> <tag> subcommands, printed with commander-style confirmation output (Successfully added/removed tag "…" …, followed by the resulting Tags: list, or (none)).
• src/cli/program.ts
  • Registered the tag command (registration lives here — src/index.ts delegates to createProgram()).
• man/sorokeep.1
  • Regenerated man page (auto-discovers commands) so the new tag command is documented.
• Tests (TDD)
  • tests/db/repositories.test.ts — new Contract Tags suite covering add/remove, the duplicate-add no-op, the missing-remove no-op, whitespace trimming, clearing the last tag to NULL, unregistered-contract errors, and the exact-match filter format.
  • tests/commands/tag.test.ts (new) — command-level coverage for both subcommands, including resulting-tag-list output and error handling for unregistered contracts.

Edge cases handled

• Adding a tag that already exists is a no-op (no duplicates).
• Removing a tag that isn't present does not error.
• Adding/removing on an unregistered contract ID produces a clear error and exits non-zero.
• Removing the last tag resets the column to NULL, keeping parity with the --tag filter's handling of empty tag sets.

Testing

npm test            # 1211 passed / 1 skipped
npx tsc --noEmit    # clean
npm run lint        # 0 errors

Also smoke-tested end-to-end against a real in-memory DB (add, duplicate add, multi-tag, remove, missing remove, remove-last → NULL, unregistered error).

Notes

• No schema change (db/schema.sql untouched) — tags continue to live in the existing contracts.tags column.
• The companion --tag filter commit (f6fb27e) exists in history but getContractsByTag is not currently present on main; interop is guaranteed by the shared comma-separated serialization rather than a shared helper.

Closes #380

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• New Features
  • Added CLI commands to add and remove tags from watched contracts.
  • Prevents duplicate tags, trims whitespace, and supports clearing the final tag.
  • Displays success or error messages for tag operations.
• Documentation
  • Updated the man page with TAG command usage and the August 1, 2026 date.
• Tests
  • Added coverage for tag creation, removal, duplicate handling, filtering compatibility, and missing contracts.

Walkthrough

The change adds tag add and tag remove CLI subcommands. Repository functions normalize and persist contract tags. Tests cover mutation behavior, errors, output, and comma-separated storage. The man page documents the new command.

Changes

Contract tag management

Layer / File(s)	Summary
Tag storage and mutation src/db/repositories.ts, tests/db/repositories.test.ts	Repository functions add and remove normalized tags, prevent duplicates, handle missing tags, use NULL for empty lists, and validate contract existence.
Tag command integration src/commands/tag.ts, src/cli/program.ts, tests/commands/tag.test.ts	The CLI registers tag add and tag remove, updates tags, prints resulting tags, logs failures, and exits with status 1 on errors.
Command documentation man/sorokeep.1	The man page documents the TAG command and updates its date.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant CLI
  participant TagCommand
  participant TagRepository
  participant Database
  CLI->>TagCommand: Run tag add or remove
  TagCommand->>TagRepository: Mutate contract tag
  TagRepository->>Database: Read and persist tags
  Database-->>TagRepository: Return stored tags
  TagRepository-->>TagCommand: Return resulting tag list
  TagCommand-->>CLI: Print success or failure

Loading

Possibly related PRs

• AbdulmalikAlayande/sorokeep#611: Both changes manage exact-match comma-separated contract tags in src/db/repositories.ts.
• AbdulmalikAlayande/sorokeep#573: Both changes modify and test contract tag handling.
• AbdulmalikAlayande/sorokeep#622: Both changes modify centralized CLI command registration in src/cli/program.ts.

Suggested reviewers: abdulmalikalayande, temi-dee

Poem

A rabbit adds a tag with care,
Then trims the spaces hiding there.
Duplicate leaves the list unchanged,
Missing tags are cleanly arranged.
The CLI prints the final state—
Hop, review, and celebrate!

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Out of Scope Changes check	⚠️ Warning	The feature changes are related, but src/cli/program.ts and man/sorokeep.1 are outside issue #380's permitted file list.	Obtain maintainer approval for the expanded scope, or limit the PR to the files and registration location specified by issue #380.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the new CLI command and its add/remove tag functionality.
Description check	✅ Passed	The description accurately explains the tag command, repository changes, tests, edge cases, and serialization behavior.
Linked Issues check	✅ Passed	The implementation covers issue #380 objectives, including tag mutation, CLI subcommands, confirmation output, edge-case tests, and serialization compatibility.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 3

🤖 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 `@src/db/repositories.ts`:
- Around line 174-190: Update addContractTag and removeContractTag to reject
trimmed tag values containing commas before parsing or persisting them, using
consistent validation and the repository’s existing error behavior. Preserve the
current handling of blank tags, and add coverage verifying comma-containing
inputs are rejected.
- Around line 174-190: Serialize the read-modify-write flow in addContractTag
and its counterpart removeContractTag by using an immediate write transaction
that holds the writer lock through tag parsing and persistence, preserving
existing validation and return behavior. Add a regression test using two
database connections that performs concurrent tag mutations and verifies neither
update is lost.

In `@tests/commands/tag.test.ts`:
- Around line 30-32: Update the afterEach cleanup in the tag tests to close the
per-test mockDb before calling vi.restoreAllMocks(), ensuring every database
created by beforeEach is deterministically released.

🪄 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: ASSERTIVE

Plan: Pro Plus

Run ID: 0f9142ac-fad3-4be8-addd-ce0565591a2f

📥 Commits

Reviewing files that changed from the base of the PR and between 2914fe5 and b0a195b.

📒 Files selected for processing (6)

• man/sorokeep.1
• src/cli/program.ts
• src/commands/tag.ts
• src/db/repositories.ts
• tests/commands/tag.test.ts
• tests/db/repositories.test.ts

📜 Review details

🔇 Additional comments (4)

src/db/repositories.ts (1)

145-165: LGTM!

src/commands/tag.ts (1)

1-61: LGTM!

src/cli/program.ts (1)

20-20: LGTM!

Also applies to: 51-51

man/sorokeep.1 (1)

1-1: LGTM!

Also applies to: 47-48

[coderabbitai]

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Reject commas in a tag value.

Line 180 accepts a,b as one tag and Lines 185-188 persist it as a,b. A later parseTags() call treats that value as two tags. This also makes exact-match filtering and the displayed result inconsistent.

Reject comma-containing values after trimming. Use the same validation in addContractTag and removeContractTag. Add coverage for this input.

Proposed fix

+function normalizeTag(tag: string): string {
+  const normalizedTag = tag.trim();
+  if (normalizedTag.includes(",")) {
+    throw new Error("Tag values cannot contain commas.");
+  }
+  return normalizedTag;
+}
+
 export function addContractTag(db: Database.Database, contractId: string, tag: string): string[] {
-  const normalizedTag = tag.trim();
+  const normalizedTag = normalizeTag(tag);
   // ...
 }

 export function removeContractTag(db: Database.Database, contractId: string, tag: string): string[] {
-  const normalizedTag = tag.trim();
+  const normalizedTag = normalizeTag(tag);
   // ...
 }

Also applies to: 200-213

🤖 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 `@src/db/repositories.ts` around lines 174 - 190, Update addContractTag and
removeContractTag to reject trimmed tag values containing commas before parsing
or persisting them, using consistent validation and the repository’s existing
error behavior. Preserve the current handling of blank tags, and add coverage
verifying comma-containing inputs are rejected.

---

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "Locate repository file and related database usage"
git ls-files | rg '(^|/)repositories\.ts$|(^|/)db/|database|better-sqlite3|sql'

echo
echo "Show relevant section of src/db/repositories.ts"
sed -n '1,260p' src/db/repositories.ts | nl -ba

echo
echo "Search for tag-related functions and database interfaces"
rg -n "function (addContractTag|removeContractTag|writeTags|parseTags|getContract)|const (addContractTag|removeContractTag|writeTags|parseTags|getContract)|class Database|interface Database|type Database" src/db/repositories.ts

Repository: AbdulmalikAlayande/sorokeep

Length of output: 1551

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "Show relevant section of src/db/repositories.ts"
sed -n '1,260p' src/db/repositories.ts

echo
echo "Search for tag-related functions in src/db/repositories.ts"
rg -n "addContractTag|removeContractTag|writeTags|parseTags|getContract|class Database|interface Database|type Database|transaction|writer" src/db/repositories.ts

echo
echo "Search database transaction/writer APIs"
rg -n "class Database|interface Database|type Database|writer|write|transaction|prepare|exec|get" src/db

Repository: AbdulmalikAlayande/sorokeep

Length of output: 34213

---

🌐 Web query:

better-sqlite3 transactions lock writer read-write locked concurrency read transaction writer lock documentation

💡 Result:

In better-sqlite3, as with SQLite generally, transaction and concurrency behavior is governed by the underlying SQLite locking model [1][2][3]. Concurrency Basics SQLite supports multiple simultaneous readers but only one writer at a time [1][4][3]. When using the default rollback journal mode, read and write operations can block each other [3]. To improve concurrency, it is standard practice in better-sqlite3 to enable Write-Ahead Logging (WAL) mode by executing db.pragma('journal_mode = WAL') [1][5]. WAL mode allows multiple readers to operate simultaneously with a single writer, as readers access the original database file while the writer appends changes to a separate WAL file [5][3]. Transaction Locks and SQLITE_BUSY The SQLITE_BUSY error occurs when the database cannot acquire the necessary lock due to concurrent activity [1][6]. 1. Deferred Transactions: By default, transactions in SQLite (and better-sqlite3) are 'deferred' [6]. They do not acquire a write lock until a write operation is actually performed [6]. If a transaction begins with a read and later attempts to perform a write, it must 'upgrade' its lock. If another connection has acquired a lock in the interim, this upgrade can cause a deadlock or SQLITE_BUSY error [7][8]. 2. Immediate Transactions: To prevent these upgrade-related deadlocks, you can use transactions that acquire the write lock immediately upon starting [7][8]. In better-sqlite3, transaction functions provide this capability (e.g., using.immediate or.exclusive variants) [9][7]. Best Practices for Concurrency - Enable WAL mode: This is the most effective way to allow concurrent read and write operations [5][4]. - Keep Transactions Short: Because SQLite serializes writes, long-running transactions hold the write lock for extended periods, blocking other writers and potentially leading to performance degradation [9][2][10]. - Use Proper Transaction Types: If a transaction will involve writing, use an 'immediate' transaction to acquire the write lock at the start, which avoids the risks associated with upgrading locks during the transaction [7][8]. - Handle SQLITE_BUSY: Even with optimizations, concurrent access can result in SQLITE_BUSY [1][4]. You should configure the database timeout (e.g., db = new Database('file.db', { timeout: 5000 })) to allow the process to wait for locks to be released before throwing an error [9][4]. It is generally advised not to mix manual transaction management (e.g., executing raw BEGIN/COMMIT commands) with the better-sqlite3.transaction helper, as this can lead to unpredictable behavior [9].

Citations:

• 1: SQLITE_BUSY with concurrent transactions is expected behavior? WiseLibs/better-sqlite3#1198
• 2: https://github.com/WiseLibs/better-sqlite3
• 3: https://www.sqlite.org/isolation.html
• 4: Multiprocess access to database WiseLibs/better-sqlite3#250
• 5: https://github.com/WiseLibs/better-sqlite3/blob/HEAD/docs/performance.md
• 6: https://sqlite.org/lockingv3.html
• 7: https://coldfusion-example.blogspot.com/2026/02/beyond-wal-optimizing-sqlite-for-high.html
• 8: https://github.com/sqlite/sqlite/blob/master/doc/wal-lock.md
• 9: https://github.com/WiseLibs/better-sqlite3/blob/HEAD/docs/api.md
• 10: Make transaction work with async callbacks. WiseLibs/better-sqlite3#1262

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "Inspect tests for tag mutation coverage and two-connection tests"
sed -n '1,260p' tests/db/repositories.test.ts
echo
rg -n "addContractTag|removeContractTag|tag" tests/db src/db tests/db/repositories.test.ts

echo
echo "Inspect database open/PRAGMA configuration"
sed -n '1,80p' src/db/database.ts

Repository: AbdulmalikAlayande/sorokeep

Length of output: 27966

---

Serialize contract tag mutations.

addContractTag and removeContractTag read the comma-separated tag list, update it in memory, then write back the full list. A concurrent tag update can overwrite the other update. Use an immediate write transaction that holds the writer lock through the read and write, or use a compare-and-swap update with retry. Add a two-connection regression test for concurrent tag changes.

🤖 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 `@src/db/repositories.ts` around lines 174 - 190, Serialize the
read-modify-write flow in addContractTag and its counterpart removeContractTag
by using an immediate write transaction that holds the writer lock through tag
parsing and persistence, preserving existing validation and return behavior. Add
a regression test using two database connections that performs concurrent tag
mutations and verifies neither update is lost.

[coderabbitai]

🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

Close the test database after each test.

beforeEach creates a new native SQLite database for every test. afterEach does not close it. Close mockDb before restoring mocks to release those resources deterministically.

Proposed fix

 afterEach(() => {
+    mockDb.close();
     vi.restoreAllMocks();
 });

📝 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

	afterEach(() => {
	vi.restoreAllMocks();
	});
	afterEach(() => {
	mockDb.close();
	vi.restoreAllMocks();
	});

🤖 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 `@tests/commands/tag.test.ts` around lines 30 - 32, Update the afterEach
cleanup in the tag tests to close the per-test mockDb before calling
vi.restoreAllMocks(), ensuring every database created by beforeEach is
deterministically released.

[muffti123]

I don't have access to push to this repo, add me as collaborator so I can push, or whats the issue I jave with this again. Let me know, I will be happy to help finish it

…

On Sat, 1 Aug 2026, 2:30 am coderabbitai[bot], ***@***.***> wrote: ***@***.***[bot]* requested changes on this pull request. *Actionable comments posted: 3* 🤖 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 ***@***.***/db/repositories.ts`: - Around line 174-190: Update addContractTag and removeContractTag to reject trimmed tag values containing commas before parsing or persisting them, using consistent validation and the repository’s existing error behavior. Preserve the current handling of blank tags, and add coverage verifying comma-containing inputs are rejected. - Around line 174-190: Serialize the read-modify-write flow in addContractTag and its counterpart removeContractTag by using an immediate write transaction that holds the writer lock through tag parsing and persistence, preserving existing validation and return behavior. Add a regression test using two database connections that performs concurrent tag mutations and verifies neither update is lost. In ***@***.***/commands/tag.test.ts`: - Around line 30-32: Update the afterEach cleanup in the tag tests to close the per-test mockDb before calling vi.restoreAllMocks(), ensuring every database created by beforeEach is deterministically released. 🪄 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*: ASSERTIVE *Plan*: Pro Plus *Run ID*: 0f9142ac-fad3-4be8-addd-ce0565591a2f 📥 Commits Reviewing files that changed from the base of the PR and between 2914fe5 <2914fe5> and b0a195b <b0a195b> . 📒 Files selected for processing (6) - man/sorokeep.1 - src/cli/program.ts - src/commands/tag.ts - src/db/repositories.ts - tests/commands/tag.test.ts - tests/db/repositories.test.ts 📜 Review details 🔇 Additional comments (4) src/db/repositories.ts (1) 145-165: LGTM! src/commands/tag.ts (1) 1-61: LGTM! src/cli/program.ts (1) 20-20: LGTM! Also applies to: 51-51 man/sorokeep.1 (1) 1-1: LGTM! Also applies to: 47-48 ------------------------------ In src/db/repositories.ts <#650 (comment)> : > +export function addContractTag(db: Database.Database, contractId: string, tag: string): string[] { + const contract = getContract(db, contractId); + if (!contract) { + throw new Error(`Contract ${contractId} is not registered.`); + } + + const normalizedTag = tag.trim(); + if (!normalizedTag) { + return parseTags(contract.tags); + } + + const tags = parseTags(contract.tags); + if (!tags.includes(normalizedTag)) { + tags.push(normalizedTag); + writeTags(db, contractId, tags); + } + return tags; *🗄️ Data Integrity & Integration* | *🟠 Major* | *⚡ Quick win* *Reject commas in a tag value.* Line 180 accepts a,b as one tag and Lines 185-188 persist it as a,b. A later parseTags() call treats that value as two tags. This also makes exact-match filtering and the displayed result inconsistent. Reject comma-containing values after trimming. Use the same validation in addContractTag and removeContractTag. Add coverage for this input. Proposed fix +function normalizeTag(tag: string): string {+ const normalizedTag = tag.trim();+ if (normalizedTag.includes(",")) {+ throw new Error("Tag values cannot contain commas.");+ }+ return normalizedTag;+}+ export function addContractTag(db: Database.Database, contractId: string, tag: string): string[] {- const normalizedTag = tag.trim();+ const normalizedTag = normalizeTag(tag); // ... } export function removeContractTag(db: Database.Database, contractId: string, tag: string): string[] {- const normalizedTag = tag.trim();+ const normalizedTag = normalizeTag(tag); // ... } Also applies to: 200-213 🤖 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 ***@***.***/db/repositories.ts` around lines 174 - 190, Update addContractTag and removeContractTag to reject trimmed tag values containing commas before parsing or persisting them, using consistent validation and the repository’s existing error behavior. Preserve the current handling of blank tags, and add coverage verifying comma-containing inputs are rejected. ------------------------------ *🗄️ Data Integrity & Integration* | *🟠 Major* | *⚡ Quick win* 🧩 Analysis chain 🏁 Script executed: #!/bin/bashset -euo pipefail echo "Locate repository file and related database usage" git ls-files | rg '(^|/)repositories\.ts$|(^|/)db/|database|better-sqlite3|sql' echoecho "Show relevant section of src/db/repositories.ts" sed -n '1,260p' src/db/repositories.ts | nl -ba echoecho "Search for tag-related functions and database interfaces" rg -n "function (addContractTag|removeContractTag|writeTags|parseTags|getContract)|const (addContractTag|removeContractTag|writeTags|parseTags|getContract)|class Database|interface Database|type Database" src/db/repositories.ts Repository: AbdulmalikAlayande/sorokeep Length of output: 1551 ------------------------------ 🏁 Script executed: #!/bin/bashset -euo pipefail echo "Show relevant section of src/db/repositories.ts" sed -n '1,260p' src/db/repositories.ts echoecho "Search for tag-related functions in src/db/repositories.ts" rg -n "addContractTag|removeContractTag|writeTags|parseTags|getContract|class Database|interface Database|type Database|transaction|writer" src/db/repositories.ts echoecho "Search database transaction/writer APIs" rg -n "class Database|interface Database|type Database|writer|write|transaction|prepare|exec|get" src/db Repository: AbdulmalikAlayande/sorokeep Length of output: 34213 ------------------------------ 🌐 Web query: better-sqlite3 transactions lock writer read-write locked concurrency read transaction writer lock documentation 💡 Result: In better-sqlite3, as with SQLite generally, transaction and concurrency behavior is governed by the underlying SQLite locking model [1][2][3]. Concurrency Basics SQLite supports multiple simultaneous readers but only one writer at a time [1][4][3]. When using the default rollback journal mode, read and write operations can block each other [3]. To improve concurrency, it is standard practice in better-sqlite3 to enable Write-Ahead Logging (WAL) mode by executing db.pragma('journal_mode = WAL') [1][5]. WAL mode allows multiple readers to operate simultaneously with a single writer, as readers access the original database file while the writer appends changes to a separate WAL file [5][3]. Transaction Locks and SQLITE_BUSY The SQLITE_BUSY error occurs when the database cannot acquire the necessary lock due to concurrent activity [1][6]. 1. Deferred Transactions: By default, transactions in SQLite (and better-sqlite3) are 'deferred' [6]. They do not acquire a write lock until a write operation is actually performed [6]. If a transaction begins with a read and later attempts to perform a write, it must 'upgrade' its lock. If another connection has acquired a lock in the interim, this upgrade can cause a deadlock or SQLITE_BUSY error [7][8]. 2. Immediate Transactions: To prevent these upgrade-related deadlocks, you can use transactions that acquire the write lock immediately upon starting [7][8]. In better-sqlite3, transaction functions provide this capability (e.g., using.immediate or.exclusive variants) [9][7]. Best Practices for Concurrency - Enable WAL mode: This is the most effective way to allow concurrent read and write operations [5][4]. - Keep Transactions Short: Because SQLite serializes writes, long-running transactions hold the write lock for extended periods, blocking other writers and potentially leading to performance degradation [9][2][10]. - Use Proper Transaction Types: If a transaction will involve writing, use an 'immediate' transaction to acquire the write lock at the start, which avoids the risks associated with upgrading locks during the transaction [7][8]. - Handle SQLITE_BUSY: Even with optimizations, concurrent access can result in SQLITE_BUSY [1][4]. You should configure the database timeout (e.g., db = new Database('file.db', { timeout: 5000 })) to allow the process to wait for locks to be released before throwing an error [9][4]. It is generally advised not to mix manual transaction management (e.g., executing raw BEGIN/COMMIT commands) with the better-sqlite3.transaction helper, as this can lead to unpredictable behavior [9]. Citations: - 1: WiseLibs/better-sqlite3#1198 - 2: https://github.com/WiseLibs/better-sqlite3 - 3: https://www.sqlite.org/isolation.html - 4: WiseLibs/better-sqlite3#250 <WiseLibs/better-sqlite3#250> - 5: https://github.com/WiseLibs/better-sqlite3/blob/HEAD/docs/performance.md - 6: https://sqlite.org/lockingv3.html - 7: https://coldfusion-example.blogspot.com/2026/02/beyond-wal-optimizing-sqlite-for-high.html - 8: https://github.com/sqlite/sqlite/blob/master/doc/wal-lock.md - 9: https://github.com/WiseLibs/better-sqlite3/blob/HEAD/docs/api.md - 10: WiseLibs/better-sqlite3#1262 <WiseLibs/better-sqlite3#1262> ------------------------------ 🏁 Script executed: #!/bin/bashset -euo pipefail echo "Inspect tests for tag mutation coverage and two-connection tests" sed -n '1,260p' tests/db/repositories.test.tsecho rg -n "addContractTag|removeContractTag|tag" tests/db src/db tests/db/repositories.test.ts echoecho "Inspect database open/PRAGMA configuration" sed -n '1,80p' src/db/database.ts Repository: AbdulmalikAlayande/sorokeep Length of output: 27966 ------------------------------ *Serialize contract tag mutations.* addContractTag and removeContractTag read the comma-separated tag list, update it in memory, then write back the full list. A concurrent tag update can overwrite the other update. Use an immediate write transaction that holds the writer lock through the read and write, or use a compare-and-swap update with retry. Add a two-connection regression test for concurrent tag changes. 🤖 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 ***@***.***/db/repositories.ts` around lines 174 - 190, Serialize the read-modify-write flow in addContractTag and its counterpart removeContractTag by using an immediate write transaction that holds the writer lock through tag parsing and persistence, preserving existing validation and return behavior. Add a regression test using two database connections that performs concurrent tag mutations and verifies neither update is lost. ------------------------------ In tests/commands/tag.test.ts <#650 (comment)> : > + afterEach(() => { + vi.restoreAllMocks(); + }); *🩺 Stability & Availability* | *🟡 Minor* | *⚡ Quick win* *Close the test database after each test.* beforeEach creates a new native SQLite database for every test. afterEach does not close it. Close mockDb before restoring mocks to release those resources deterministically. Proposed fix afterEach(() => {+ mockDb.close(); vi.restoreAllMocks(); }); 📝 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 - afterEach(() => { - vi.restoreAllMocks(); - }); + afterEach(() => { + mockDb.close(); + vi.restoreAllMocks(); + }); 🤖 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 ***@***.***/commands/tag.test.ts` around lines 30 - 32, Update the afterEach cleanup in the tag tests to close the per-test mockDb before calling vi.restoreAllMocks(), ensuring every database created by beforeEach is deterministically released. — Reply to this email directly, view it on GitHub <#650>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B3MZGLQJU5MWHTHAK6W2JWL5HVBZ7AVCNFSNUABGKJSXA33TNF2G64TZHMYTCMZXG43TCMJWG45US43TOVSTWNJQGM2DKOBVGMYTFILWAI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[AbdulmalikAlayande]

Thanks for the detailed PR body and thorough test coverage — I implemented this directly on main (commit 7942674) rather than merging the PR since the branch was 100 commits / 1137 files behind current main. The design (addContractTag/removeContractTag, comma-separated tags format, no-op duplicate-add and missing-remove semantics, NULL on last-tag removal) was clean and reused nearly verbatim.

One small change: tightened two catch (error: any) blocks in tag.ts to unknown, matching a no-explicit-any cleanup pass this repo did earlier this cycle.

Closing this PR since the work is captured on main now — appreciate the care taken here.