What are the risks involved in using custom decorators as validation pipes in Nestjs?

Background

A data structure in my database consists of "sections"; lists of custom objects. The number of sections may expand in the future, so to keep my code as DRY as possible, I wanted to determine the section to add/update/delete an item from to be defined dynamically as a parameter.

I quickly realised that doing something like @Body() section: SectionA | SectionB | SectionC... disables validation so I needed a single DTO Section that could encompass all sections. To do that I need to define dynamically which validators to apply as I have several @IsNotEmpty constraints.

So I came across this post whose selected answer recommends the usage of groups.

This posed the following challenges:

1. I now have to write a custom validation pipe. Relied heavily on this
2. I want to override the global validator pipe that I already had running and use my custom one for just that method. Outcome: didn't work, had to start defining the pipe on every controller method, a tradeoff I am willing to accept. Looks like there is no simple alternative.

However, I'm now faced with the final problem: how to use the parameters in the request to define these groups in the validator; another brick wall. No simple solution.

Solution

This question has been asked here but no satisfactory solution was actually given.

Option one recommended redefining the scope of the pipe to "request" level but didn't explain how, and solutions found online didn't work.

The second solution, using a custom decorator to perform the validation instead, did work, very well in fact here is a simplified version of the code:

export const ProfileSectionData = createParamDecorator(
  async (data: unknown, ctx: ExecutionContext) => {
    const request = ctx.switchToHttp().getRequest();

    let object = plainToInstance(SectionDto, request.body); // I don't need to access the metatype from the request because I know what type I need but I'm sure I could if need-be.

    const groups = [request.params.profileSection];
    let validatorOptions = { groups, ...defaultOptions };

    const errors = await validate(object, validatorOptions);
    if (errors.length > 0) {
      throw new BadRequestException();
    }
    return request.body;
  },
);

Implications?

Here's my question. When Jay McDoniel recommended using a custom decorator, they warn: "Do note, that this could impact how the ValidationPipe is functioning if that is bound globally, at the class, or method level."

What does this mean? Are there any vulnerabilities or performance drawbacks associated with this solution?

Obviously, one drawback is that you are using validation outside a validation pipe which is not ideal from a point of view of order and single-responsibility but I can't think of tangible inconveniences beyond aesthetics and maintainability.

Knowing the background, would you have approached the problem in a completely different way?