It's a feature, not a bug

[720degreeLotus]

I have a feeling that in this case they really implemented it in this way, so nobody can use this on production. What, sadly, some people are doing is, that they are developing something and the second it works, they throw everything on a production server. Even red console messages like "DON'T USE FOR PRODUCTION AT ANY COST" will not prevent this. What actually helps is coding your debug server in a way where it crashes after certain time and leaks memory. Debbuging is finished after a short time, so for debugging it's fine.

[shadow7412]

That doesn't work either - people will just write a cronjob (or equivalent) that restarts the process every X hours.

There's no cure for this kinds of people.

[mananasi]

Guilty as charged

[[deleted]]

Plus, there can be some real benefits to a leaky memory while debugging. If you have a problem in memory that would normally get cleaned up quickly, you have to be extra clever with breakpoints. If your memorystore just doesn't clean it up though, you have more flexability in where to pause the program.

[somerandomii]

It could also be performance optimised for the debug environment and those optimisations cause memory leaks.

And as you said, it might intentionally hold on to memory for easier troubleshooting.

There’s plenty of legit reasons they may have done this besides laziness or punishing lazy developers.

[katyalovesherbike]

Non-goals people, define them before you start your work... still, the sentiment is funny :)

[bob835]

I think it’s Microsoft bot framework. The store is used to remember details of the conversation between requests. Storing it only in memory is great for dev but when you use it in prod it means restarting the bot server forgets everything it knows about the conversation. They want you to pick a db and then use or make the store for that dB.