Kiota generator logging and observability

[baywet]

We need to align with hidi and provide a good observability experience.

Questions that still need to be answered:

• Are kiota/hidi going to be hosted as a service? (ILogger vs System.Diagnostics)
• What are the parameters for logging levels? (ll or v?)
• What are the logging levels? (review whether ILogger is aligned with Open Telemetry)
• Where do we need scopes/activities?
• Do we still need the stop watches?

[nikithauc]

Adding to the observability point,

The current design of TypeScript maps a request body object to the model class at the time of request as follows:

interface User {
name: string
}
const user: User = {
name: "xyz"
} 

const createdUser = await clients.users.post(user);

In the post function, the user object is mapped to a new UserImpl model class instance. This implementation detail is abstracted from the user.

If the user adds a property to the request body that does not exist in the generated model interface, example const user = {name : "xyz", someNewProp : 123232 }, or a custom class with additional properties implementing the model class, then new properties will not be mapped and not forwarded to the API. This would be ambiguous to the user not aware of the implementation detail.

[baywet]

Sorry @nikithauc I gave you the wrong issue, I meant #618

[baywet]

Meeting notes: Instrumenting the code to have spans for the code under the hood of Kiota would not be super helpful due to the complexity of the code and how nested the spans are going to be. If somebody hosts Kiota as a service, they can configure the logger they pass to output to OpenTelemetry or system.diagnostics and get an overview of the whole generation process as a single span. No actions to take on our side. Closing.