Curious what the impetus is for this change.
Since I actually use this, not in favor ^^
What is the reasoning?
Will there be another solution to do something after reply like post handlers or?
@devinivy I want to remove features that add overhead but are rarely used.
@AdriVanHoudt The only reason to use this was if you want to log requests after the tails are done. Otherwise, you can just use normal node facilities to do stuff after you call reply().
@hueniverse hmm true, I do think we log the tail time with good atm not the response time.
Also will I be able to do request.log without a tail?
As long as you keep a reference to the request, sure. But keep in mind this is not a great pattern. You are holding resources for no real reason past the time the request lifecycle is done.
the only reason I do atm is so it logs the log with the request context, I could probably/maybe work around that
I just pass the request id along to later methods for context and make sure it’s included in logs. Works for me.
Sorry to bring this up after this issue has been closed, but I thought it worth mentioning, we have a number of endpoints that we serve that are fire-and-forget. It is very convenient to be able to see the log of request.log events within our response logs. we can associate the request id with the log events as described above, but it does add some effort every time we want to query the logs in splunk, etc. Obviously this isn't a showstopper, but this feature will definitely be missed by some of us.
You can easily accomplish this yourself.
This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.
Most helpful comment
@devinivy I want to remove features that add overhead but are rarely used.
@AdriVanHoudt The only reason to use this was if you want to log requests after the tails are done. Otherwise, you can just use normal node facilities to do stuff after you call
reply().