[gunian]

how else would one reproduce a bug? in production?

or is it best practice to patch with logs only without reproduction

[blenderob]

> how else would one reproduce a bug? in production?

I don't think they meant "either" "or". I think they meant that you should not solely rely on reproducing issues locally. If you have good logging, many times, the logs would make it apparent where the issue is. When that fails, then you resort to reproducing the issue locally.

But if an app developer never adds any logs, they would be forced to reproducing the issue locally every single time which is counter productive.

So it isn't either logs or reproduce locally. It is add logs and read logs. But also reproduce locally when you really have to.

[bripkens]

There are often additional hints to go by, e.g., the executed network requests, the user path taken or "breadcrumbs", i.e., custom events captured.

Of course that requires a certain operational maturity.

[gunian]

In my head that feels like triaging but idk people really be patching bugs without reproducing? That sounds crazy to me idk why

I've never worked at a place that had local dev used to think computers hated me but wondering if this is better dev practice in general

[nottorp]

Who said anything about not reproducing?

It just takes a lot less time to reproduce if you have some logging in production... and some people seem to believe that's not needed.

And if you have logs, you may not need to reproduce it because said logs give you all the info you need.

Disclaimer: circumstances may vary. A bug is a bug is a bug and you may solve it by reading one log line, or you may spend a week with a debugger in your development environment and it will still crash in production when you deploy the fix.

Happy now?