feat(microservices): add redis driver identification by vchomakov · Pull Request #16218 · nestjs/nest

vchomakov · 2026-01-19T18:41:13Z

PR Checklist

Please check if your PR fulfills the following requirements:

The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
Tests for the changes have been added (for bug fixes / features)
Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

What is the current behavior?

Issue Number: N/A

Currently, when NestJS applications connect to Redis (via microservices or Socket.IO adapter), Redis administrators cannot easily identify which connections are from NestJS applications. The connections appear as generic ioredis or node-redis clients without any framework identification.

What is the new behavior?

This PR adds Redis driver identification by implementing the clientInfoTag option for both ioredis and node-redis clients. This allows Redis administrators to identify which framework (NestJS) and version is connecting to Redis.

Changes:

Added clientInfoTag option to IORedisOptions interface in packages/microservices/external/redis.interface.ts
Implemented automatic NestJS version detection via getClientInfoTag() method in:
- packages/microservices/client/client-redis.ts (ioredis client)
- packages/microservices/server/server-redis.ts (ioredis server)
- sample/02-gateways/src/adapters/redis-io.adapter.ts (node-redis adapter)
Added tests to verify default behavior and custom override capability
Uses getOptionsProp() helper for consistency with NestJS codebase conventions

Behavior:

Default: Automatically detects NestJS version from package.json and sets clientInfoTag to nestjs_v{version} (e.g., nestjs_v11.1.12)
Fallback: If version detection fails, falls back to nestjs
Override: Users can provide custom clientInfoTag in their Redis options:

{
  transport: Transport.REDIS,
  options: {
    clientInfoTag: 'custom-tag'
  }
}

Result:
Redis connections will now be identified as:

ioredis (microservices): ioredis(nestjs_v11.1.12)
node-redis (Socket.IO adapter): node-redis(nestjs_v11.1.12)

This information is sent to Redis via the CLIENT SETINFO LIB-NAME command and can be viewed by Redis administrators using CLIENT LIST or CLIENT INFO.

Reference: https://redis.io/docs/latest/commands/client-info/

Does this PR introduce a breaking change?

Yes
No

Other information

Backward Compatibility: Older versions of ioredis or node-redis that don't support clientInfoTag will simply ignore the unknown option, ensuring backward compatibility.

Testing:

All existing tests pass (1897 passing)
Added unit tests for getClientInfoTag() method
Code formatted with npm run format
Code linted with npm run lint

coveralls · 2026-01-19T18:45:16Z

Pull Request Test Coverage Report for Build 66039487-f8ce-46c0-91b7-c99d3dc61810

Details

2 of 2 (100.0%) changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.03%) to 89.776%

Totals
Change from base Build 8b740f1b-28b5-4612-8936-d2a0f00b572a:	0.03%
Covered Lines:	7446
Relevant Lines:	8294

💛 - Coveralls

kamilmysliwiec · 2026-01-20T08:05:52Z

Instead of auto-retrieving the @nestjs/microservices packagae version, we could just add the clientInfoTag configuration attribute so users can specify them (manually, if needed) in the strategy options object.

vchomakov · 2026-01-20T17:28:57Z

Instead of auto-retrieving the @nestjs/microservices packagae version, we could just add the clientInfoTag configuration attribute so users can specify them (manually, if needed) in the strategy options object.

@kamilmysliwiec, Thanks for the suggestion!
I've added clientInfoTag as a configurable option in the strategy options object in this commit.

Additionally, it auto-detects the NestJS version as a sensible default (e.g., nestjs_v11.1.12), allowing users to override it with any custom value:

{
  transport: Transport.REDIS,
  options: {
    clientInfoTag: 'custom-tag'
  }
}

kamilmysliwiec · 2026-01-21T07:52:27Z

    }
  }
+
+  protected getClientInfoTag(): string {


Can we please remove this (as suggested in the previous PR)? No need to auto-set it for everyone

@kamilmysliwiec do you mean entirely removing the default value (e.g., nestjs_v11.1.12)? Wouldn't this result in having the client info tag as unset in most environments?

That's fine - it's been unset by default for +7 years now. We should let end users decide if they want tags to be used

@kamilmysliwiec,

Client info is already being sent in recent node-redis versions following Redis recommendation for CLIENT SETINFO

Client libraries are expected to pipeline this command after authentication on all connections

We're not introducing new data transmission here, just enhancing the existing client info with upstream framework name following the official guide.

Currently: node-redis
With this change: node-redis(nestjs)

This is important information for Redis maintainers to optimize for specific frameworks, fix framework-specific issues, and debug production systems.

Users can still override the clientInfoTag value if they wish to erase framework information (note that node-redis/ioredis client info would still be sent by the driver libraries regardless of this PR).

the current default (node-redis) seems fine though, what's the reason for adding the (nestsjs) suffix there? even if you have multiple nestjs services, you'd end up with duplicated tags.

I understand the concern, but I think making this opt-in would significantly reduce its usefulness in practice.

If this were opt-in, most users would likely never configure it, which means the CLIENT SETINFO data would largely be missing — even though it’s primarily intended to help Redis operators rather than application authors. That’s why Redis recommends client libraries provide this information by default.

This also preserves existing behavior in node-redis, where client info is already sent in an opt-out fashion. We’re not changing that model here, just extending the information with upstream framework context in line with the Redis guidance.

For additional context, this pattern is also reflected elsewhere in the ecosystem. For example, fastify-redis appends framework-level client information by default, while still allowing users to override or disable it:
https://github.com/fastify/fastify-redis/blob/66ee62a1333c474d50c66a55c687628a94757f76/index.js#L24-L57

So overall, keeping this opt-out:

maintains parity with node-redis,

aligns with Redis CLIENT SETINFO recommendations,

and remains fully overridable for users who don’t want framework-level identification.

Happy to improve documentation or make the opt-out path more explicit if that helps address the concern.

Could you please update it as suggested above, otherwise i won't be able to merge this PR

@kamilmysliwiec
Would a simpler default of just nestjs (without the version) address your concern? This removes the auto-retrieval of the package version while still providing framework identification for Redis admins by default.

Users could still override (clientInfoTag: 'my-app') or disable (clientInfoTag: '') as needed.

@kamilmysliwiec done!

Copilot

Pull request overview

Adds Redis client identification metadata so Redis administrators can distinguish NestJS-originated connections (via ioredis microservices clients/servers and the sample Socket.IO adapter).

Changes:

Added clientInfoTag to the Redis (ioredis) options surface.
Set a default clientInfoTag derived from the NestJS package version (with fallback), while allowing user override.
Added unit tests around getClientInfoTag() and client creation paths.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
sample/02-gateways/src/adapters/redis-io.adapter.ts	Sets `clientInfoTag` for the sample node-redis client and adds version-based tag helper.
packages/microservices/external/redis.interface.ts	Exposes `clientInfoTag` on `IORedisOptions`.
packages/microservices/client/client-redis.ts	Applies `clientInfoTag` when constructing ioredis clients and adds `getClientInfoTag()`.
packages/microservices/server/server-redis.ts	Applies `clientInfoTag` when constructing ioredis servers and adds `getClientInfoTag()`.
packages/microservices/test/client/client-redis.spec.ts	Adds tests for `createClient()` and `getClientInfoTag()`.
packages/microservices/test/server/server-redis.spec.ts	Adds tests for `createRedisClient()` and `getClientInfoTag()`.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

kamilmysliwiec · 2026-03-10T08:49:32Z

LGTM

feat(microservices): add redis driver identification

b796a7f

feat(microservices): add redis client info tag with auto version

a3120d5

kamilmysliwiec reviewed Jan 21, 2026

View reviewed changes

kamilmysliwiec requested a review from Copilot February 2, 2026 16:25

Copilot started reviewing on behalf of kamilmysliwiec February 2, 2026 16:26 View session

Copilot AI reviewed Feb 2, 2026

View reviewed changes

vchomakov added 2 commits February 3, 2026 15:17

refactor(microservices): extract redis client info tag to shared utility

8a021fa

test(microservices): Verify clientInfoTag is applied to redis client

15836f7

vchomakov requested a review from kamilmysliwiec March 6, 2026 16:21

vchomakov added 2 commits March 10, 2026 00:33

feat(microservices): make redis client info tag opt-in only

b80791e

chore(microservices): remove unused redis client info util test

20924e9

kamilmysliwiec added type: enhancement 🐺 scope: microservices labels Mar 10, 2026

kamilmysliwiec merged commit 4141992 into nestjs:master Mar 10, 2026
2 checks passed

Uh oh!

Conversation

vchomakov commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Checklist

PR Type

What is the current behavior?

What is the new behavior?

Does this PR introduce a breaking change?

Other information

Uh oh!

coveralls commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Pull Request Test Coverage Report for Build 66039487-f8ce-46c0-91b7-c99d3dc61810

Details

💛 - Coveralls

Uh oh!

kamilmysliwiec commented Jan 20, 2026

Uh oh!

vchomakov commented Jan 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kamilmysliwiec commented Mar 10, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

vchomakov commented Jan 19, 2026 •

edited

Loading

coveralls commented Jan 19, 2026 •

edited

Loading