-
Notifications
You must be signed in to change notification settings - Fork 509
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(azure-functions): redirect console to azure context for logging #542
Conversation
export async function handle (context, req) { | ||
const url = '/' + (req.params.url || '') | ||
|
||
interceptLogging(context) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this have issues with logs being associated to the wrong request if there are multiple parallel requests?
If not (that is, if there is only one aggregated logging bucket), then do we need to run this on every incoming request or could we early return if the interceptor has already been run?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I understand it, it is a single logging bucket for the whole function app.
We could optimize and dont intercept ,if we are already intercepting.
The gains do not outweight the potentiell bugs, in my opinion, with the added complexity we get.
I rather intercept twice than miss a critical log.
Regarding my comment:
I'm checking with the Azure team to ensure that there are no downsides to this approach. |
Changed deprecated ```useBody()``` to ```readBody()```. fixes: nitrojs#789
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
β¦rt (nitrojs#812) Co-authored-by: Pooya Parsa <pooya@pi0.io>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
β¦s` (nitrojs#883) * feat(fetch): allow for futher narrowing of the method option * style: simplify fetch options type
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
* fix: don't overwrite proxy headers if already set * perf: only call `getHeaders()` once --------- Co-authored-by: Mike Bellika <mike@altinget.dk>
Typo on the Heroku deployment page
* refactor: improve code readability * implement stable tree
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Any updates on this? |
ah F thats not what I wanted About the concerns that we associate logs of different requests with each other. |
In that case I think we need a different approach, almost certainly not overwriting |
I will close this as the long-term option will be an For the short term I will continue to patch nitro in my CI with the |
I agree that |
π Linked issue
#383
β Type of change
π Description
At the moment there is no easy way to run nitro in an azure-funtions context and retain the ability to log out.
This pr redirects the built in
console.log(),console.warn(),console.info() and console.error()
to the azure provided logging context.This adresses #383 ,but should be refined in the future to allow a more flexible log target
π Checklist