Issue on ctx object when updating to 26.3.1

[Youssefbenmlih]

When i update to 26.3.1 my use of ctx.field does not work anymore.

my factory functions a bit like so :

     public create(type: PipelineType, options?: { acl?: ACLS, group?: boolean }) {
        switch (type) {
            case PipelineType.APPROVER:
                return this.applyApproverSecurity(options?.acl)
                    .addMiddleware(this.approversAuthorized.verifyApproverRemoteWorkRequestsRights())
                    .addMiddleware(EzaMiddleware(JournalApi.logExpress(Config.REMOTE_WORK)));
            default:
                throw new Error(`Middleware type ${String(type)} is not supported by this factory.`);
        }
    }

    private applyApproverSecurity(acl?: ACLS) {
        if (!acl) throw new Error("ACL is required for Approver pipelines");

        return this.core
            .addMiddleware(EzaMiddleware(authorizedHasCompte()))
            .addMiddleware(EzaMiddleware(authorizedApprovers.verifyAclApprover(acl)));
    }

and my middleware returns :
return { accessibleLeaveIds, ctx, request, response };

But it seems that in the routing accessing accessibleLeaveIds through ctx.accessibleLeaveIds generates :
the Property 'accessibleLeaveIds' does not exist on type '{ headers: IncomingHttpHeaders; } & { metrics: MetricManager; } & { request: Request<ParamsDictionary, any, any, ParsedQs, Record<...>>; response: Response<...>; }'.

It seems to me that the issue is TypeScript's inability to narrow the union type from the factory method.

Everything works fine in 26.3.0 ctx.accessibleLeaveIds is recognized and it's typing is correct.

[RobinTail]

Hello, @Youssefbenmlih

I can't figure out the cause from your samples, but, taking into account the given type of ctx in the error, I suspect that the presence of accessibleLeaveIds is not obvious or is somehow conditional. Perhaps, the middleware providing that property is itself conditionally added to the factory. Or maybe you're doing .addMiddleware() inside a function that has predefined type of its returns.
I can also see you having something called EzaMiddleware which is a custom entity that may interfere with ctx recognition.

Consider the following pattern:

1. Ensure having an instance of ResultHandler
2. Use that instance to create a new EndpointsFacory()
3. Make several child-factories from that one, with required combinations of the middlewares for your goals using .addMiddleware() sequentially.
4. Use those child-factories to produce Endpoint using .build() method

That approach is straightforward and has no conditional assignment.
Check out the example dir of this repo for inspiration.