Confusing debug logs by ConversationStore

[Mogadampalli-Jayanth]

I am developing one bot
It is throwing error when I send message to bot
This is the following error:
bolt-app Conversation context failed loading for ID:<channeID>, error: Conversation not found
Please provide solution to resolve this error!

[seratch]

@Mogadampalli-Jayanth Thanks for flagging this! I do understand this debug message is confusing particularly for developers that don't use the conversation store. https://github.com/slackapi/bolt-js/blob/%40slack/bolt%402.3.0/src/conversation-store.ts#L67

@stevengill @aoberoi (and other maintainers)
Considering the situation where most developers do not use the feature, I think it's about time to reconsider the debug logs caused by conv store. Thoughts?

[vvvprabhakar]

+1

[aoberoi]

Thanks for starting this discussion, I think it’s too confusing too!

Do you think we should no longer add the conversationContext middleware by default? This change would require a major version change, and I don’t think this is high enough impact for the project to trigger the next major version to happen. Therefore this may take several months. It would also decrease compatibility for users migrating from Hubot, and we’d like to keep the compatibility high since there will be a wave of developers migrating as new Platform features are released in the next 3 - 6 months.

Do you think we should remove this log line completely? For a developer who is using the conversationContext middleware, we need to offer some means to debug and understand the situation where the ConversationStore doesn’t return any data. Do we have another idea for how we should do this?

Should we explore “scoped” loggers? In theory, using the DEBUG level means most people shouldn’t see this log line unless they are actively debugging. But in practice, people who are actively debugging are mostly not even aware that the conversationContext middleware exists, which leads to this confusion. We also have a general problem where the inheritance of loggers from App to other objects (e.g. ExpressReceiver, InstallProvider, even WebClient) is not intuitive or clear. Maybe this problem is closely related in that log levels are not enough to describe which parts of the application you expect to hear from. Do we have any ideas?

[seratch]

related issue: #680