mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-09-21 06:12:17 +03:00
db5ae3c33d0fe21b93bc4e353e8a9e94ee2d2ada
3 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
anhtahaylove
|
fde6241d41 |
test: close the database before removing temp DATA_DIR (#13290) (#13292)
* test: close the database before removing temp DATA_DIR (#13290) Tests that set their own DATA_DIR and removed it in test.after() failed on Windows with EPERM: nothing closed the SQLite connection, so the directory still had an open handle and the -shm/-wal sidecars kept it locked. maxRetries could not help because every retry hit the same open handle. Adds tests/_setup/tempDataDir.ts with cleanupTempDataDir()/createTempDataDir(), which close the DB singleton (lazily imported, so tests that never touch the database do not pull in the DB layer) and then remove the directory best-effort. Applies it to the five suites confirmed failing. The helper's own test proves the ordering matters: skipping the close makes it fail with 'cleanup must remove the directory'. * test: close the database before removing temp DATA_DIR (15 more suites) Converts the suites that measurably emitted EPERM during a full run to the shared cleanupTempDataDir helper from #13292. Measured on the same 15 files: base -> 22 fail, 40 EPERM lines branch -> 7 fail, 10 EPERM lines The 7 remaining failures are pre-existing and unrelated to teardown: rtk-learn-discover-routes and executor-map-golden already fail on a clean base (6 and 3 failures respectively). * test: close the database before removing temp DATA_DIR (final 9 suites) Completes the #13290 sweep. Two teardown shapes needed the helper: - after()/t.after() hooks that removed DATA_DIR directly - beforeEach() hooks that wiped DATA_DIR between tests while the previous test's connection was still open. These failed *before* the test body ran, so every test in the file reported the same EPERM path. Three of them already called core.resetDbInstance() right before rmSync and still leaked, which is the product-side connection leak tracked in #13303. Measured per file, EPERM lines now 0 across all nine. Remaining failures are pre-existing on a clean base (firefly 4->1, driverFactory 1, responses-* 1 each) and unrelated to teardown. * test: add the missing cleanupTempDataDir import to two responses suites The previous commit swapped rmSync for cleanupTempDataDir in these two files but did not add the import, so both suites died with ReferenceError: cleanupTempDataDir is not defined before running any test. responses-parse-once-4041: 0 pass / 1 fail -> 4 pass / 0 fail responses-route-early-keepalive-wiring: 0 pass / 1 fail -> 3 pass / 0 fail Both now report 0 EPERM. * test: close SQLite handles in three silently-leaking suites These three suites requested DATA_DIR cleanup but the delete failed on Windows because a SQLite connection was still open. They pass today, so the leak is invisible: they carry state between tests and would surface later as an unrelated-looking assertion, as #13303 already did in the Firefly suite (a 500 instead of a 401). agentbridge-mitm-router-key-6403 and agent-bridge-bypass-flow removed their own temp dir in test.after() without closing the DB first; both now use the shared cleanupTempDataDir helper, which closes the singleton before removing the directory. issue-agent-route-execution is a different case: it has no teardown at all, so the connection stayed open until process exit and the isolateDataDir cleanup hook then hit EPERM. It now closes the DB in test.after(). Verified with a probe on fs.rmSync: all three reported a failed delete before, and zero across three consecutive runs after, while the same probe still reports four leaks in the Firefly suite. * test: remove temp DATA_DIR in five suites that never cleaned up These five suites create their own mkdtemp DATA_DIR, open the SQLite DB and never remove the directory, so every run leaves a storage.sqlite behind in the OS temp dir. Each dir is private to its suite, so this leaked disk space rather than corrupting results - but the churn is pointless. Each now closes the DB and removes its directory through the shared cleanupTempDataDir helper. Verified with an exit-time probe that lists storage.sqlite* still present in DATA_DIR: it fired for these suites before the change and is silent after, with the same test counts (22/14/5/3/3 passing). |
||
|
Diego Rodrigues de Sa e Souza
|
3d4f3e4960 |
test(infra): retry recursive temp-dir removal instead of failing a shard on ENOTEMPTY (#11966) (#11968)
* test(infra): retry recursive temp-dir removal instead of failing a shard on ENOTEMPTY (#11966) Two shards on release/v3.8.51 went red in one day with the same signature — "ENOTEMPTY, Directory not empty: /tmp/omniroute-<test>-XXXXXX" — from combo-same-provider-cascade (Unit Tests fast-path 4/4, on a PR that touches only .github/) and auth-policy-embeddings-webfetch-7785 (the 20k-test TIA step). Both pass alone and on re-run: the cleanup races something still writing into the directory (SQLite WAL/-shm checkpoint, a worker, the backup) and under a loaded hosted runner the window opens. 1154 test files do their own cleanup with fs.rmSync(dir, { recursive: true, force: true }); 57 already asked for retries. One-shot codemod (scripts/ad-hoc/codemod-rm-maxretries.mjs, kept for the record): every rm / rmSync / rmdirSync option object with `recursive: true` and no `maxRetries` gains `maxRetries: 5, retryDelay: 100` — Node itself then retries ENOTEMPTY/EBUSY/EPERM for up to ~0.5 s before giving up. 2243 call sites in 1292 files under tests/, the shared tests/_setup/isolateDataDir.ts exit hook included. Only the option object changes: no call site, assertion or import is touched. Validation: prettier and ESLint (with the frozen suppressions) clean on all 1292 files; a random 20-file sample runs green (quota-redis-store hangs identically on the untouched tree — it needs a Redis on localhost, an environment matter). The four unit shards on this PR are the full run. * fix(quality): let check-forgotten-sibling-tests read a 1,000-file diff The gate shells out to `git diff` through execFileSync with Node's default 1 MB maxBuffer; the 1,292-file codemod in this PR is the first diff large enough to overflow it, and the gate died with `spawnSync git ENOBUFS` before comparing anything. 64 MB is far above any real PR and costs nothing when unused. |
||
|
KooshaPari
|
f657c7865a |
feat(issue-agent): surface RecordedTriageTimeoutError as 504 (#7315)
* chore(ci): add .mergify.yml to main — Mergify only reads config from the default branch (#7168)
* feat: scaffold issue agent and router eval provenance
* feat: wire recorded issue triage runner
* feat: ingest recorded issue context
* feat: persist issue agent audit log
* feat: import recorded github issue exports
* docs: document issue agent env toggle
* fix(issue-agent): validate run requests
* fix(ci): add the auto-enqueue pull_request_rule to the Mergify config (queue_conditions alone are eligibility-only) (#7179)
* fix: validate issue agent run requests
* docs: add issue agent execution traceability
* feat(issue-agent): route recorded triage through chat
* test(issue-agent): verify recorded triage through chat route
* docs(issue-agent): add executable triage session artifacts
* fix(ci): migrate Mergify auto-enqueue to merge_protections_settings.auto_merge_conditions (rules-based path is EOL 2026-07-16) (#7216)
* fix(ci): drop Mergify batch settings (batching is a paid-tier feature; free plan queue is serial) (#7220)
* feat(issue-agent): surface RecordedTriageTimeoutError as 504
When the recorded-triage chat completion times out, the AbortController
fires an AbortError that previously surfaced as a generic 400 to the
caller. This change:
* Adds a `RecordedTriageTimeoutError` that wraps the AbortError
with the timeoutMs context.
* Re-throws it from `executeRecordedTriageChatCompletion` so the
caller can distinguish timeouts from other failures.
* In the runs route, catches it and returns a 504 with code
`ISSUE_AGENT_TIMEOUT` so clients can render a useful error.
Tests:
* issue-agent-execution.test.ts — verifies the typed error
* issue-agent-route-execution.test.ts — covers timeout path
* issue-agent-runs-route.test.ts — verifies 504 mapping
* fix(ci): merge queue tolerates the advisory dast-smoke failure (its GH-hosted build hang dequeued every attempt) (#7225)
* test(ci): make the #6634 selfref guard hermetic — main's copy hard-fails every PR (#7341)
main's copy of this test still does git I/O inside a unit test:
const baseSrc = git(['show', 'origin/main:' + FILE]);
Runners check out a shallow single ref, so origin/main does not resolve and the
test dies with 'fatal: invalid object name origin/main'. Every PR into main
fails Unit Tests (7/8) on it — today that is #7313, #7315, #7316, #7334, #7336
and #7337, six PRs red on a defect none of them introduced. #7313 has no other
red at all.
release/v3.8.49 already carries a fix (
|