Conversation
Increase beforeEach delay from 100ms to 1000ms and set describe-level timeout to 15000ms for the Server properties block. After Shutdown and BringOnline operations, the Firebird service needs more time to settle before subsequent service operations can succeed. Co-authored-by: mariuz <18359+mariuz@users.noreply.github.com>
Copilot
AI
changed the title
[WIP] Review failing test after mocha to vitest switch
Fix intermittent timeout in service.js Server properties tests
Feb 16, 2026
Vitest runs test files in parallel by default, but mocha (the previous test runner) ran them sequentially. test/index.js and test/service.js share a Firebird server and interfere with each other when running concurrently - service.js shuts down and modifies the database while index.js tries to query it, causing random timeouts in both files. Also reverts the unnecessary beforeEach delay increase and describe timeout override from the previous attempt, since sequential execution eliminates the root cause. Co-authored-by: mariuz <18359+mariuz@users.noreply.github.com>
Copilot
AI
changed the title
Fix intermittent timeout in service.js Server properties tests
Fix vitest parallel file execution causing intermittent CI timeouts
Feb 16, 2026
Co-authored-by: mariuz <18359+mariuz@users.noreply.github.com>
Root cause: vitest runs each test file in a separate worker process
(fork), causing different database names per worker and abrupt TCP
connection termination between files. On Node 22, this leaves Firebird
in a transient state where the service.js worker can't connect within
the 10s hook timeout.
Fix:
- vitest.config.js: add maxWorkers: 1 and isolate: false (vitest 4 API)
to run all files in one process, matching mocha's original behavior
- test/index.js: fix Object.assign(config) -> Object.assign({}, config)
to prevent config mutation now that modules are shared across files
Co-authored-by: mariuz <18359+mariuz@users.noreply.github.com>
Copilot
AI
changed the title
Fix vitest parallel file execution causing intermittent CI timeouts
Fix vitest test isolation: run all files in single process to match mocha behavior
Feb 17, 2026
Copilot
AI
changed the title
Fix vitest test isolation: run all files in single process to match mocha behavior
Fix test isolation: prevent "Lock time-out" errors on read-only/read-write property tests
Feb 17, 2026
With isolate: false, all test files shared the same module cache, meaning test/index.js and test/service.js used the same database path. Unclosed connections from test/index.js (especially event manager connections) held locks that prevented service.js from changing the database access mode (read-only/read-write). Reverting to the default isolate: true gives each test file its own module evaluation with a unique timestamp-based database path, eliminating cross-file connection interference. Co-authored-by: mariuz <18359+mariuz@users.noreply.github.com>
Copilot
AI
changed the title
Fix test isolation: prevent "Lock time-out" errors on read-only/read-write property tests
Fix vitest test isolation to prevent lock timeout errors in service tests
Feb 17, 2026
The beforeAll hook in test/service.js calls Firebird.attachOrCreate() to create the test database, which can take longer than the default 10000ms hookTimeout (inherited from testTimeout) on CI — especially on Node 22 where each test file runs in its own forked process. Setting hookTimeout: 30000 gives hooks 30 seconds for database creation and connection setup while keeping testTimeout at 10 seconds for individual tests. Co-authored-by: mariuz <18359+mariuz@users.noreply.github.com>
Copilot
AI
changed the title
Fix vitest test isolation to prevent lock timeout errors in service tests
Fix vitest config for mocha-to-vitest migration
Feb 17, 2026
With isolate: true (vitest 4 default), the module cache is cleared between test files but socket objects survive in the same worker. test/index.js Events tests leak event manager connections that are never closed. When modules are re-loaded, old sockets interfere with new Firebird connections, causing attachOrCreate() to hang forever. Using isolate: false avoids module cache clearing. Reordering to run service.js BEFORE index.js ensures service tests (which need exclusive database access for read-only/read-write mode changes) run first with no competing connections. Index tests run last, so any leaked event connections don't affect subsequent exclusive-access operations. Co-authored-by: mariuz <18359+mariuz@users.noreply.github.com>
Copilot
AI
changed the title
Fix vitest config for mocha-to-vitest migration
Fix vitest config: reorder test files and restore isolate: false
Feb 17, 2026
The FbEventManager.close() method was missing a callback invocation on success - it ended the socket but never called the callback, causing fromCallback(cb => evtmgr.close(cb)) to hang forever. Also added proper cleanup in all Events tests by calling evtmgr.close() after each test. Previously, event managers created via db.attachEvent() were abandoned without cleanup, leaking TCP sockets that could interfere with subsequent test files sharing the same Firebird server. Co-authored-by: mariuz <18359+mariuz@users.noreply.github.com>
Copilot
AI
changed the title
Fix vitest config: reorder test files and restore isolate: false
Fix vitest config and event manager resource leaks after mocha-to-vitest migration
Feb 17, 2026
When close() calls closeEvents on the main connection, the Firebird server may also send a stale op_event notification on the event connection before the socket is fully closed. The eventcallback handler processes this and calls loop(false) -> queEvents, pushing a spurious callback onto the main connection queue. The next operation (e.g. auxConnection from a subsequent attachEvent) then gets the wrong response from the queue, causing it to hang indefinitely. Fix: Set eventconnection.eventcallback = null at the start of close(), before calling closeEvents. The existing guard in the event connection data handler (if self.eventcallback) safely handles the null case. Co-authored-by: mariuz <18359+mariuz@users.noreply.github.com>
Copilot
AI
changed the title
Fix vitest config and event manager resource leaks after mocha-to-vitest migration
Fix vitest test isolation and event manager resource leaks after mocha migration
Feb 17, 2026
testProperty called service property setters (setReadonlyMode etc.) which return readable streams via _createOutputStream, but never drained them. Undrained streams keep the Firebird service operation running, holding internal locks on the database. setReadonlyMode and setReadwriteMode need exclusive access and fail when previous undrained operations still hold the database. Fix: drain the service output stream with readStreamAsync before calling getStats. Also make the Events afterAll resilient to connection queue corruption from event operations by racing db.detach() against a 5s timeout and force-closing the socket if detach didn't complete. Co-authored-by: mariuz <18359+mariuz@users.noreply.github.com>
Copilot
AI
changed the title
Fix vitest test isolation and event manager resource leaks after mocha migration
Fix test failures after mocha-to-vitest migration
Feb 17, 2026
Same race condition as close(): when _changeEvent sends closeEvents + queEvents on the main connection, a stale op_event notification can arrive on the event connection and trigger eventcallback -> loop(false) -> push spurious queEvents onto the main connection queue. This misaligns the callback queue so closeEvents's response gets consumed by the wrong callback, and registerEvent's callback never fires. Fix: Temporarily null out eventconnection.eventcallback at the start of _changeEvent (matching the pattern in close()), and restore it after queEvents completes so the event loop can resume normally. Co-authored-by: mariuz <18359+mariuz@users.noreply.github.com>
Copilot
AI
changed the title
Fix test failures after mocha-to-vitest migration
Fix event manager race conditions and test teardown after mocha-to-vitest migration
Feb 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
After switching from mocha to vitest, tests failed intermittently due to vitest's different isolation/parallelism defaults exposing pre-existing race conditions in the Firebird event system that mocha's sequential single-process execution masked.
Event manager race conditions (
lib/wire/fbEventManager.js)The event loop's
eventcallbackcan fire between any two operations on the main connection, pushing a spuriousqueEventscallback onto the queue. This misaligns the callback queue so subsequent operations consume the wrong response and hang.close(): Null outeventcallbackbeforecloseEventsto prevent re-queuing from staleop_eventnotifications_changeEvent(): Same fix — suppresseventcallbackduringcloseEvents+queEvents, restore after completionclose()callback: Was never invoked on success, causingawait-style callers to hang foreverTest fixes
test/index.js: Close event managers after each test; resilientafterAllwith timeout + force socket close; fixObject.assign(config)→Object.assign({}, config)no-optest/service.js: Drain readable streams returned by service property setters before callinggetStats— undrained streams hold Firebird server locks, causing "Lock time-out" onsetReadonlyMode/setReadwriteModeVitest configuration (
vitest.config.js)isolate: false,fileParallelism: false,maxWorkers: 1— match mocha's single-process sequential execution modelhookTimeout: 30000— database creation hooks need headroom on CIservice.jsbeforeindex.jssince service tests need exclusive DB access💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.