Repository navigation
chore(deps): Bump fast-uri from 3.1.0 to 3.1.2 - #123
Closed
dependabot[bot] wants to merge 1 commit into
Closed
dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [fast-uri](https://github.com/fastify/fast-uri) from 3.1.0 to 3.1.2. - [Release notes](https://github.com/fastify/fast-uri/releases) - [Commits](fastify/fast-uri@v3.1.0...v3.1.2) --- updated-dependencies: - dependency-name: fast-uri dependency-version: 3.1.2 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
github-actions
Bot
added
the
type:chore
@connectum/auth
@connectum/cli
@connectum/core
@connectum/events
@connectum/events-amqp
@connectum/events-kafka
@connectum/events-nats
@connectum/events-redis
@connectum/healthcheck
@connectum/interceptors
@connectum/otel
@connectum/reflection
@connectum/testing
commit: |
Contributor
Author
|
Looks like fast-uri is no longer updatable, so this is no longer needed. |
Contributor
|
@dependabot recreate |
Contributor
Author
|
Looks like this PR is closed. If the branch still exists, you can re-open the PR and then use |
Merged
13 of 16 tasks
intech
added a commit
that referenced
this pull request
Oct 10, 2026
…pics out of wildcards (#332) ## Summary Three wildcard-subscription defects found by a live run against real brokers: `@connectum/events-nats` ran the handler once per matching pattern of a subscription (3 times for `user.created` with the routes `user.created`, `user.*`, `user.>`); `@connectum/events-kafka` subscribed Kafka's internal `__consumer_offsets` for a catch-all `>`, and never consumed a topic created after the subscription. - **NATS.** Every pattern keeps its own durable consumer, exactly as in earlier versions: same names, same filters, same positions. A message matched by several patterns reaches the adapter once per consumer; the handler runs for the delivery of the most specific pattern among those whose consumer delivers it (an order derived from the pattern text, equal on every replica), and the other deliveries are acknowledged without running it. Upgrading and rolling back need no action and no queue is replaced. - **NATS never writes to the broker.** The adapter reads the consumers it finds and never changes their configuration, so rolling back to 1.2 keeps working (verified with the published `@connectum/events-nats@1.2.0` on nats-server 2.9.25, 2.10.29 and 2.15.0), and consumers provisioned by an operator need only read and pull permissions (verified with a user that cannot create consumers). Replicas compute where each consumer starts from what the server reports; a delivery below the delivering consumer's own bound always runs the handler, so replicas that disagree can duplicate a handler run, never skip one. - **NATS, also fixed.** An unacknowledged delivery of an existing consumer used to be acknowledged away without running the handler when a wider route was added (found while reviewing this change; reproduced on all three servers, red before and green after). A failing `subscribe()` used to delete a consumer of the same group that existed before the call (present on `main`); it now deletes only the consumers of an auto-generated group, and leaves those of a named group for the next start. An existing consumer made with another `ackWait`, `maxDeliver` or `deliverPolicy` is kept and reported with one warning per consumer. Two replicas racing to create one consumer are handled. - **Kafka.** A pattern that opens with a wildcard no longer matches topics starting with `__` (exactly the topics Kafka and Redpanda mark internal; Redpanda's `_schemas` is not internal and is still received by `>`). New `consumerOptions.topicDiscoveryInterval` (`number | false`), **on by default at 300 000 ms** (`false` turns it off), picks up topics created after the subscription and logs each discovery with the topic names. In a group of several members a new topic is read completely after the longest interval among the members (KafkaJS assigns partitions only from the group leader's topic list); nothing is lost meanwhile. - **Redis.** The rejection of wildcard patterns is documented and pinned by a test. - **CI.** A `NATS JetStream` job runs the NATS integration tests on nats-server 2.9.25 (the oldest supported line), 2.10.29 and 2.15.0 for the first time. Docs companion: Connectum-Framework/docs, branch `docs/events-adapters-wildcard-defects`. ## Decisions - **Kafka discovery is on by default.** The repository rule is that behaviour-changing defaults are opt-in, with an exception for a silent loss of data, and this loss was measured by the independent review and re-measured by the implementer on a live broker (6 runs each on apache/kafka 4.2.0 and Redpanda v25.3.10, identical in all 12): a topic created after the subscription, five messages published to it, the service restarted, a sixth message published. Discovery off, restart after 5 s: the group handled only the sixth (5 of 6 never handled, no line in the log), because a restart reads a new topic from its end. Discovery 1000 ms, restart after 8 s: all 6 handled, the first run having handled and committed 5. Discovery 60 000 ms, restart after 3 s (before the first check): the same 5 lost. So with discovery on, the loss is gone unless the service restarts inside one interval before a check has seen the topic; that window is a property of Kafka (a group without a committed offset starts at the end) and is documented. The three measurements are permanent integration tests. Cost: one metadata request per wildcard subscription every five minutes on one extra admin connection per adapter, and a group rebalance when a matching topic appears. `false` restores the fixed list of earlier versions. The changeset and the highlights say it changes a default. - **NATS: no write to the broker.** The first design recorded the start sequence in consumer metadata (`connectum.start_seq`). Measured: after that write the published 1.2.0 cannot subscribe on nats-server 2.10.29 and 2.15.0 (`consumer already exists`, API error 10148), which breaks a rollback and the restart of a 1.2 replica during a rollout. The write was removed; the bounds are read only, and the delivery rule above makes the replicas safe whatever bounds they hold. - **NATS: duplicates, not losses.** While a service is rolled out with a route added to a broader pattern, an event can be handled by both the old and the new replicas (measured: replicas `[user.>]` and `[user.created, user.>]`, 30 events, 0 lost, 15 handled twice). The same can happen when replicas attach at different times while a wider consumer still lags behind a narrower one, and when a consumer holds a delivery that was never acknowledged. This is the at-least-once contract; handlers must tolerate redelivery. - **NATS: network copies remain.** The server still sends one copy per matching pattern (as before); only the handler runs once. - **NATS: consumers of removed routes** stay on the broker as before and keep growing; they are not deleted automatically because deleting a consumer under a running replica silently stops its delivery (measured and pinned by a test). The cleanup command is documented. - **Kafka: `__` rule has no switch.** Anyone who relied on a catch-all to read `__consumer_offsets` loses it; a pattern that spells the prefix out and literal topic names still work. - **Kafka integration tests: topic readiness.** The branch includes the commit that waits for topic metadata instead of trusting `waitForLeaders` (also proposed separately): without it the suite on apache/kafka 4.2.0 failed a different test on each run with "This server does not host this topic-partition". ## Type of change - [x] Bug fix (non-breaking) - [x] New feature (changes the default behaviour of Kafka wildcard subscriptions; `false` restores the old behaviour) - [ ] Breaking change (documented in migration guide) - [x] Documentation / chore / internal ## Test plan - [x] `pnpm --filter @connectum/reflection build:proto`, `pnpm --filter @connectum/cli build:proto`, `pnpm turbo run build` (20/20), then `pnpm turbo run typecheck test` (50/50, 0 type errors; events-nats 32 and events-kafka 90 unit tests; most other tasks replayed from the turbo cache) - [x] `pnpm exec biome check .` after the full build: exit 0, no warnings; `pnpm lint:rules` 5/5; TypeDoc (`--emit none`) exit 0; `pnpm release:gate` PASS; `pnpm test:bun` and `pnpm test:esbuild` 35/35 tasks each - [x] Red before, green after: the scenarios "attaching leaves the configuration untouched, so the earlier version can create it again", "an unacknowledged delivery of an existing consumer is handled after a wider route is added" and the unit tests of the own-bound rule, of the Kafka default and of the discovery log fail on the previous sources and pass on the new ones - [x] NATS integration 26/26 and 0 skipped on nats-server 2.9.25, 2.10.29 and 2.15.0; the NATS suites also pass under Bun (2.10.29, 5 suites) - [x] Rollback with the published `@connectum/events-nats@1.2.0`: this version attaches to consumers made by 1.2.0 and handles events, then 1.2.0 subscribes again and handles events, on 2.9.25, 2.10.29 and 2.15.0; the consumers' metadata stays empty. Before: a metadata write made 1.2.0 fail with 10148 on 2.10.29 and 2.15.0 - [x] Least privilege: consumers made beforehand, a user without `$JS.API.CONSUMER.CREATE.>`: `subscribe()` succeeds and the events are handled - [x] Mutations, each fails the intended tests: ownership disabled, own-bound clause removed, the metadata write put back, rollback deleting every durable, the "already exists" branch removed, Kafka default turned off, `false` not recognised, `__` guard removed, discovery not started, discovered topic not read from the beginning - [x] Kafka integration 30/30 on apache/kafka 4.2.0 and on Redpanda v25.3.10 (including the skewed-interval scenario); the suites also pass under Bun on Kafka; Redis 13/13 on redis 6.2 and valkey 9.1.1; AMQP 14/14 on rabbitmq 4.3.6 - [x] Examples with tarballs packed from this branch (md5 of `dist/index.js` equal to the tarball, lockfiles restored): with-events-dlq (NATS) 5/5, with-events-kafka 5/5, with-events-redpanda 5/5, with-events-valkey 5/5, hris 36/36, car-sharing 49/49; `scaffold:check --combo events-nats` ok. with-events-amqp passes 5/5 in some runs and 4/5 in others ("multiple orders processed correctly": the order service handles `InventoryReserved` before it stores the order); with the published packages from the committed lockfile it fails the same test in 3 of 5 runs, so it is a race in the example, not in the adapter, and events-amqp is not changed here - [ ] Not measured: whether `ack_floor` moves past a message that exhausted `max_deliver` (affects the number of duplicates only); a Kafka group mixing members with and without discovery; the size of the metadata answer on a cluster with thousands of topics ## Parity coverage - [ ] Parity coverage added - [x] Parity N/A: the change concerns event-bus adapter subscriptions (NATS, Kafka) and documentation; it does not change observable RPC behaviour and does not touch the HTTP/2 or in-process transports. ## Related issues / changes Related: #329 (AMQP `>` semantics, not touched here; the docs companion points the AMQP row to the AMQP page because AMQP `>` matches zero segments on main until #329 merges). Docs PRs #123/#126 edit the same pages as the docs companion (`custom-topics.md` conflicts with #126). Before merging: the new CI check `NATS JetStream (nats-2.9.25)` has never run on GitHub. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01FoznWr9X2vr4VDNvKtknvf Docs companion: Connectum-Framework/docs#128 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Kafka wildcard subscriptions exclude internal topics from broad matches and discover newly created matching topics every five minutes by default. Discovery can be disabled. * NATS subscriptions run handlers only for the most-specific matching pattern, reducing duplicate event handling. * **Bug Fixes** * Redis subscriptions with unsupported wildcard patterns now fail with a clear error instead of silently receiving no events. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Code <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.
Bumps fast-uri from 3.1.0 to 3.1.2.
Release notes
Sourced from fast-uri's releases.
Commits
919dd8eBumped v3.1.2c65ba57fixup: linting6c86c17Merge commit from forka95158aHandle malformed fragment decoding without throwing (#171)cea547cBumped v3.1.1876ce79Merge commit from forkdcdf690ci: add lock-threads workflow (#169)c860e65build(deps-dev): bump neostandard from 0.12.2 to 0.13.0 (#167)9b4c6dcbuild(deps): bump fastify/workflows/.github/workflows/plugins-ci.yml (#166)85d09a9build(deps): bump fastify/workflows/.github/workflows/plugins-ci-package-mana...Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)You can disable automated security fix PRs for this repo from the Security Alerts page.