Improve error message for circular dependencies in SchemaObjectFactory

[miquelferrando]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

When a circular dependency occurs during Swagger schema generation, the error message is generic: Error: A circular dependency has been detected (property key: "someKey").

In large projects or monorepos with hundreds of DTOs, knowing only the property name (e.g., "user", "filters", "id") is insufficient to locate the problematic class. It often requires tedious debugging or binary search (commenting out code) to find the source of the cycle.

Describe the solution you'd like

I propose improving the error handling in SchemaObjectFactory, specifically within the extractPropertiesFromType method.

By wrapping the property extraction logic in a try-catch block, we can capture the error, prepend the name of the class (prototype) being processed, and re-throw it.

Proposed change logic:

// In SchemaObjectFactory.extractPropertiesFromType
try {
   // ... existing logic calling mergePropertyWithMetadata
} catch (err) {
   const className = type.name || 'Unknown';
   err.message = `[${className}] ${err.message}`;
   throw err;
}

This transforms the error from:
ERROR MY.uncaughtException:Error: A circular dependency has been detected (property key: "someProperty") ...

To:
ERROR MY.uncaughtException:Error: [RootResponseDTO] [ParentEntity] [ChildEntity] A circular dependency has been detected (property key: "someProperty") ...

Teachability, documentation, adoption, migration strategy

This is a non-breaking change that significantly improves the Developer Experience (DX).

Adoption: Automatic. Users will simply see better error messages when they upgrade.
Documentation: No documentation changes required for the public API.
Migration: None needed.

What is the motivation / use case for changing the behavior?

The motivation is to drastically reduce debugging time. Circular dependencies are common in complex data models. Identifying the specific class causing the cycle allows developers to immediately apply the fix (using lazy resolvers type: () => Class or forwardRef) instead of hunting for the file.

[AzatF2020]

I also agree that in the current implementation, it is not very clear how I can find the problem with circular dependency, which creates a problem when debugging