Improvements - #69
Open
llambeau wants to merge 12 commits into
Open
Conversation
Fix a bug in JobRunner where RAW mode crashed because updateMetrics() was called without null checks in the promise resolution/rejection handlers of #doRun. Replace broken proxyquire usage in consumer, server, and REST API tests with direct imports and sinon stubs. Add tests for: runner RAW mode (7 tests), NodeJSRunner RAW mode (unskip), dispatcher invalidJobExchange path, dispatcher queue push failures, consumer stop() and multi-config, and server stop(). Test count goes from 219 passing + 1 failing to 251 passing + 0 failing. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Round 2: AmqpQueue operations tested with mocked amqplib and fetch stubs using sinon sandboxes. Covers _connect (retry logic, event propagation), _push (serialization, exchanges, headers), _consume (ACK/NACK, invalid JSON, null messages), _disconnect, _requeue (shovel creation, errors), _getQueuesInfo (management API, error handling), and deriveManagementUrl. Round 3: New test files for ConsumerConfig and JobResult. Config edge cases (malformed YAML, config without schema files). Richer validator tests (optional fields, nested objects, type coercion). Binary runner stderr tests changed from skip to pending. Test count: 309 passing, 0 failing (up from 251). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
All core components now accept explicit dependencies instead of reaching into the Arnavon singleton: - JobDispatcher: accepts optional registry and queue params - JobRunner/ensureMetrics: accepts optional registry param - createApi: accepts optional registry in options - Server: accepts optional registry and queue, passes to dispatcher/API - Consumer: accepts optional registry and queue, stores and uses them - REST API: accepts queue and config through options - NodeJSRunner: accepts cwd in config instead of using Arnavon.require() Every parameter defaults to Arnavon.* when not provided, so the CLI path and all existing tests work unchanged (309 passing, 0 test changes). Arnavon.cwd() and Arnavon.require() are marked @deprecated. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…Phase 2) ArnavonConfig.from(options) allows building config from plain TypeScript objects without YAML or Finitio. Defines TypeScript interfaces for JobDefinition, ConsumerDefinition, QueueDefinition, and ArnavonOptions. JobValidator now accepts either a Finitio.System or a plain validator function (data) => data, enabling Zod/Joi/custom validation. ConsumerConfig accepts a handler function as alternative to runner config. FunctionRunner wraps the handler with the same metrics/lifecycle as other runners. New exports: ValidatorFn, HandlerFn, ArnavonOptions, JobDefinition, ConsumerDefinition, QueueDefinition, RunnerDefinition. 321 passing tests (12 new), 0 failing. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
New ArnavonApp class provides an instance-based API for using Arnavon
as a library:
const app = new ArnavonApp({ queue: { driver: 'amqp', config: {...} } })
app.job('send-email', { validate: (d) => schema.parse(d) })
app.consumer('mailer', { queue: 'emails', handler: async (job) => {...} })
await app.startApi({ port: 3000 })
Features:
- Fluent API with .job() and .consumer() chaining
- .startApi(), .startConsumer(name), .startAllConsumers()
- .fromYaml(path) convenience for YAML-based config
- Own prometheus registry per instance (no singleton dependency)
- Exported as named export: import { ArnavonApp } from '@quadrabee/arnavon'
CLI commands rewritten to use ArnavonApp.fromYaml() internally, removing
all direct references to the Arnavon singleton from CLI code.
335 passing tests (14 new), 0 failing.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…gistry When using ArnavonApp (which has its own registry and doesn't set the Arnavon singleton), Consumer._startConsuming() created runners via JobRunner.factor() without passing a registry. The runner constructor fell back to Arnavon.registry which was undefined, causing a crash. Now Consumer passes its registry through factor() → RunnersFactory → runner constructor. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
NodeJSRunner, BinaryRunner, and FunctionRunner constructors were not accepting or forwarding the registry parameter to the JobRunner base class. The factory passed (config, registry) but subclass constructors only accepted (config), so the registry was silently dropped. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ArnavonApp doesn't set Arnavon.config, so NodeJSRunner's fallback to Arnavon.cwd() crashed with 'Cannot read properties of undefined'. Consumer now accepts a cwd parameter and injects it into the runner config when factoring runners. ArnavonApp passes its cwd through. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
llambeau
force-pushed
the
improvements-20260402
branch
from
April 2, 2026 14:01
fb1e75d to
e42330b
Compare
Brings every dependency to its latest usable version. 1416 -> 786 packages, 58 -> 0 npm audit vulnerabilities, test suite unchanged at 335 passing / 2 pending on both Node 20 and Node 22. Major bumps: oclif 1->4, express 4->5, amqplib 0.10->2, chai 4->6 (with chai-http 5, chai-as-promised 8, sinon-chai 4), eslint 7->10, sinon 17->22, mocha 10->11, nyc 15->18, typescript 5.3->5.9. Node floor moves to >=20. Toolchain: - Drop Babel entirely. `build` was already pure tsc; `build:watch` is now `tsc --watch` and tests transpile through tsx. This also removes core-js, regenerator-runtime, ts-node and babel-loader, none of which were referenced anywhere. - Replace the eslintrc config with flat config. The rules previously supplied by @enspirit/eslint-config-node are inlined into eslint.config.mjs, as that package is eslintrc-only and pins the deprecated babel-eslint. - The old `eslint src **/*.ts` invocation only ever linted a handful of files (eslint 7 lints just .js for a directory arg, and `**/*.ts` collapsed to one level). `eslint .` now covers the whole tree, which surfaced ~80 pre-existing problems; all are fixed here. - Switch to moduleResolution node16, which is what surfaced the two ESM-only packages handled below. - Replace deprecated `pkg` with the maintained @yao-pkg/pkg fork. - Pin diff/serialize-javascript via overrides to clear mocha's transitive advisories without downgrading mocha. Fixes found along the way: - src/ required @babel/register at runtime while it sat in devDependencies, so installs of the published package would fail with MODULE_NOT_FOUND. The replacement transpiler is a real dependency, and user-supplied modules now load through src/user-module.ts, which registers the tsx hook only for the duration of that load rather than globally. - oclif 4 removed ux.table, so queues:status needs @oclif/table, which is ESM-only and pulls in a top-level-await dependency that cannot be require()d from this CommonJS build. It is loaded via dynamic import(). This was crashing `arnavon --help`. - uuid went ESM-only in v11 and cannot be required from this build, so src now uses node:crypto randomUUID via src/uuid.ts. uuid stays as a devDependency so tests validate against an independent implementation. - Attach `cause` to six error rethrows that previously discarded the underlying failure. Test suite: - chai 6 has no default export: specs use named `expect`/`use`/`should`, and chai-http 5's `request.execute()` replaces `chai.request()`. - Specs now start with 'use strict'. tsx compiles them to CommonJS, which unlike tsc's output for dist/ does not otherwise imply strict mode; the difference was silently masking a JobResult immutability assertion. - express 5 builds app.settings with a null prototype, so the createApi duck-type check asserts shape rather than `instanceof Object`. finitio stays on 1.x (2.x requires Node >=22.12) and typescript on 5.9 (typescript-eslint 8 caps TypeScript at <6.1.0). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Test against Node 20, 22 and 24 rather than 20 alone, so the declared engines floor is actually exercised. The integration job builds a docker image, so it stays gated to a single version. - Bump pinned actions: checkout v2->v5, setup-node v2->v5, docker/login-action v1->v3. - Base image node:20-alpine -> node:22-alpine. - CLAUDE.md: commands are npm (the repo has package-lock.json and the Makefile shells out to npm; there is no yarn.lock), plus notes on the tsx test loader, the flat eslint config and src/user-module.ts. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The integration suite pins neither the rabbitmq image nor the gems
resolved inside the webspicy tester, and it had not run green since
2026-04-02. Two independent upstream changes broke it in the meantime.
Neither is related to the dependency upgrade: a container running the
previous published arnavon image fails identically.
rabbitmq:4-management now refuses transient non-exclusive queues by
default ("Feature `transient_nonexcl_queues` is deprecated"), so both
the api and the workers died on connect with AMQP 541 and exited 10.
The send-email-via-binary queue is declared durable now; the feature is
slated for removal from RabbitMQ entirely, so there is no reason for the
example to keep exercising it.
amq-protocol dropped Ruby 2.7 support after 2.7.0, but the webspicy
tester image ships Ruby 2.7.3, so `gem install bunny` no longer resolves
and the image failed to build - which took down `up`, and with it both
test targets. Pin amq-protocol before installing bunny.
Verified locally: `make test.integration` exits 0, with test.example at
99 assertions / 0 failures and test.arnavon at 30 assertions /
0 failures, against a locally built image.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
No description provided.