fix #28

We recently had a problem with pino in hapi, because hapi is unable to create the request.url object when the URL is invalid, see this gist

You can use those to write to any file descriptor.

Something around 5%? Probably not worth it. Have you tried going with fs.write and writev and bypassing the wrap?

Seems like a side effect that may not be evident to users, and thus they'd fail to reimplement it when they use a custom formatter.

This come from experience. There is a significant amount of devs that asked for a similar feature to be removed from Fastify. If I move it outside of the errorFormatter, I would need to add a new option. By putting it in the errorFormatter, I leave it to the user by default.

You have already researched for similar issues?

Yes, but I didn't find anything related to this issue.

What are you trying to achieve or the steps to reproduce?

When I started to create a simple app with Fastify version 3.2.0, It gives me some errors. But after downgrading to version 2.15.3, problem solved

// simple hello world index.js

const fastify = require("fastify")({
  logger: true,
});

// Declare a route
fastify.get("/", function (request, reply) {
  reply.send({ hello: "world" });
});

// Run the server!
fastify.listen(3000, function (err, address) {
  if (err) {
    fastify.log.error(err);
    process.exit(1);
  }
  fastify.log.info(`server listening on ${address}`);
});

What was the result you received?

The result with version 3.2.1:

{"level":50,"time":1597419681847,"pid":6792,"hostname":"MY-PC-NAME","generatedMessage":false,"name":"AssertionError [ERR_ASSERTION]","code":"ERR_ASSERTION","actual":false,"expected":true,"operator":"==","stack":"AssertionError [ERR_ASSERTION]: Version should be a string
at Router._on ([PATH-TO-PROJECT]\\node_modules\\find-my-way\\index.js:98:5)
at Router.on ([PATH-TO-PROJECT]\\node_modules\\find-my-way\\index.js:73:8)
at Object.afterRouteAdded ([PATH-TO-PROJECT]\\node_modules\\fastify\\lib\\route.js:221:16)
at after ([PATH-TO-PROJECT]\\node_modules\\fastify\\lib\\route.js:167:25
at Object._encapsulateThreeParam ([PATH-TO-PROJECT]\\node_modules\\avvio\\boot.js:545:7)
at Boot.timeoutCall ([PATH-TO-PROJECT]\\node_modules\\avvio\\boot.js:447:5)
at Boot.callWithCbOrNextTick ([PATH-TO-PROJECT]\\node_modules\\avvio\\boot.js:428:19)
at Boot._after ([PATH-TO-PROJECT]\\node_modules\\avvio\\boot.js:273:26)
at Plugin.exec ([PATH-TO-PROJECT]\\node_modules\\avvio\\plugin.js:131:17)
at Boot.loadPlugin ([PATH-TO-PROJECT]\\node_modules\\avvio\\plugin.js:266:10)","type":"Error","msg":"Version should be a string"}

What did you expect?

Anything but not an error.

Context

• node version: 10.20.1
• fastify version: >=3.2.0
• os: Windows
• I start the server using nodemon

This is fixed already, update your dependencies. Sorry for the problem :(

The problem here is that I had absolutely not clue on why some code I wrote was not working on windows as the code was working smoothly on Linux and Mac. The developer experience for this was far from great, because the only way to debug this would be to have a Windows machine

One other option we can consider here would be to improve the error message in the case of an absolute windows path.

I think this would be the bare minimum change that improve the developer experience.

import fastify from 'fastify';
const { fastifyRequestContextPlugin } = require('fastify-request-context');
const server = fastify({
    logger: true
});
const preValidationFn = (req, reply, done): any => {
    req.requestContext.set('hello', 'hello world');
    console.log(req.requestContext.get('hello'));
    done();
};
const handlerFn = (req, reply): any => {
    console.log(req.requestContext.get('hello'));
    reply.send('hello world');
};
server.route({
    url: '/test',
    method: ['GET', 'POST'],
    preValidation: preValidationFn,
    handler: handlerFn
});

server.register(fastifyRequestContextPlugin);
console.log('Starting fastify Typescript server ');
server.listen(8085, '0.0.0.0', (err, address): void => {
    if (err) {
        console.warn(err);
        process.exit(1);
    }
    console.info(`Server listening at ${address}`);
});


process.on('uncaughtException', error => {
    console.error(error);
});
process.on('unhandledRejection', error => {
    console.error(error);
});

This is my fastify server written in typescript while using the fastify-request-context plugin I am able to access the context of fastify request when I am requesting the resource using the GET method, But I am not able to access the context of fastify request if I am requesting the resource using POST method

This is the stackoverflow link

https://stackoverflow.com/questions/63325150/fastify-request-context-is-not-working-for-post-api-calls

As titled

I would probably store this in a symbol instead

You should add

fastify.decorateRequest('asyncResource', null)

Added a few feature - which enables us to filter the logs bases event tags.

@naseemkullah I think so, yes! See https://www.npmjs.com/package/@elastic/ecs-pino-format as an example for a custom config for a specific cloud provider.

Can you rebase? This now conflicts with master.

That's possible, the core request is available.

Currently hapi-pino provides ignorePaths and ignoreTags. They are useful to a certain degree, but for some cases it's still impossible to silent hapi-pino for some routes.

The use case I have in mind are routes for static files (which are usually defined with path: /foo/bar/{file*}). I want those to be silent. I can add a tag to these routes and use that tag in ignoreTags. That will work for the "request completed" log, however the "request start" log will still happen (because that log is defined in the onRequest extension point, and at that point the route is not yet located).

I'd like to propose a 3rd ignore option:

options.ignoreFunc: (options, Request) => boolean

It would be a simple addition to the internal isLoggingIgnored function: if option.ignoreFunc is present, it will execute and return the value; else, it will proceed with the current logic (which will check ignorePaths and ignoreTags, and also returns a boolean).

These 3 ignore options wouldn't be compatible obviously (either use ignorePaths/ignoreTags or ignoreFunc).

This way hapi-pino would provide the maximum flexibility to the user. If there's interest in this feature I would make a pr.

Thanks for considering.

I think you can call done of the callback form and get that expected result.

Do you think that monkey-patching request EE from the plugin is an acceptable solution?

Not really. I think we should attach the context to fastify request and call the preValidation callback with that attached.

I think this can be done by manually doing something inside the 'preValidation' hook. @puzpuzpuz do you think it would be possible to create a custom AsyncResource there and restore it in that way?

<!-- Before you submit an issue we recommend you visit Fastify Help and ask any questions you have or mention any problems you've had getting started with Fastify.

Please read this entire template before posting any issue. If you ignore these instructions and post an issue here that does not follow the instructions, your issue might be closed, locked, and assigned the missing discussion label. -->

🚀 Feature Proposal

Add a new plugin option to exclude a list of routes prefixes from the auth check.

Motivation

Sometimes you want to have security set to all routes except 1 or few routes. This option will simplify this process and avoid to have to register the plugin for all the routes except the one you want to exclude.

I am currently working on a side project and I would like to have fastify-swagger enabled in a staging or test environment however still secure those.

Example

fastify.register(bearerAuthPlugin, {
    keys: new Set(keys),
    excludePrefixes: enableSwagger ? ['/documentation'] : undefined
});

Does the docker-compose up command accept an argument for a custom docker compose config filename?

Yes, I think it is

docker-compose -f docker-compose-v7.yml up

But I can be wrong, take a look at the docs.

send a PR, no real need

But there is no docker-compose.yml file, there are currently five files starting matching docker-compose-*.yml. I'm not exactly sure what to do with that, maybe you could amend the instructions?

We use multiple docker-compose to test against different ElasticSearch versions. Can you send a PR to fix?

Bumps summary from 1.0.0 to 2.0.0. <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/AndreasMadsen/summary/commits">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot will merge this PR once CI passes on it, as requested by @mcollina.

Note: This repo was added to Dependabot recently, so you'll receive a maximum of 5 PRs for your first few update runs. Once an update run creates fewer than 5 PRs we'll remove that limit.

You can always request more updates by clicking Bump now in your Dependabot dashboard.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in the .dependabot/config.yml file in this repo:

• Update frequency
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

</details>

Let's leave it like this and see if the CPC needs some changes first.

The build was successful. Just code coverage is dropped by 0.07% because of if check.

No worries

CI is failing, can you take a look?

cc @nodejs/modules

@Eomm this should have had approval by the OpenJS Foundation CPC before landing :)

@ronag I think that's not sustainable. Most load balancer would consider this similar to DoS attack

remove?

+1

Can you please describe a bit your setup? Have you got some routes you need to send the cookies and some routes you don't?

Normally filtering is expensive compared to do something only when needed. Can you please articulate why you can't just avoid to call setCookie() when you do not need it? Also why would you not create a new decorator that wrapped reply.setCookie() and apply that filtering?

I'm happy to assist/review.

Yes!

🚀 Feature Proposal

Add an index.d.ts with Typescript type definitions.

Motivation

To use it on Typescript projects.

I can do a PR for this if you are ok with it.

I think we could close this for now as it seems we will be waiting until exports is more mature.

We are currently quite busy. If you send a PR we'll be happy to review, otherwise it would have to wait for a bit.

onRequest happens before preValidation.

I don't think it should be reinitialized, but probably something must be done to retain the context.

oh ok.

@StarpTech can you open an issue on node core on this and tag me on it? Thanks. This is very confusing.

I was following @mcollina tutorial for Fastify, and I faced with an error related to fastify-autoload plugin:

Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only file and data URLs are supported by the default ESM loader
    at Loader.defaultResolve [as _resolve] (internal/modules/esm/resolve.js:781:11)
    at Loader.resolve (internal/modules/esm/loader.js:85:40)
    at Loader.getModuleJob (internal/modules/esm/loader.js:229:28)
    at Loader.import (internal/modules/esm/loader.js:164:28)
    at importModuleDynamically (internal/modules/cjs/loader.js:1199:27)
    at exports.importModuleDynamicallyCallback (internal/process/esm_loader.js:30:14)
    at loadPlugin (C:\Users\amis\Desktop\fastify3-test\node_modules\fastify-autoload\index.js:117:5)
    at C:\Users\amis\Desktop\fastify3-test\node_modules\fastify-autoload\index.js:27:12
    at Array.map (<anonymous>)
    at fastifyAutoload (C:\Users\amis\Desktop\fastify3-test\node_modules\fastify-autoload\index.js:26:29) {
  code: 'ERR_UNSUPPORTED_ESM_URL_SCHEME'
}

I'm running Node v14.7.0 on Windows 10. This is how the app looks like:

app.js

import fastify from 'fastify'
import autoload from 'fastify-autoload'
import { join } from 'desm'

export default function (opts) {
    const app = fastify(opts)

    app.register(autoload, {
        dir: join(import.meta.url, 'routes')
    })

    return app
}

/routes/hello.js

export default async function (app) {
    app.get('/', async function (req, rep) {
        return { hello: 'world' }
    })
}

Released as v3.0.8!

please use async functions instead.

please set 0 as the port and use app.server.address() to get the actual port. There is no need to use 0.0.0.0 either.

I think we might want to run this on multiple hooks as well, maybe it should be an array?

Do not wrap with a promise, use an async function. .listen() returns a promise if a callback is not passed in.

I'm totally lost on why Buffer.isBuffer would work, but hey.

please just wrap server listen in a Promise, and do not use async functions inside new Promise.

why the heck this works on Mac and Linux then? :)

I would highly recommend to not use jest as it provides different globals for each test, making all those check fail. Anyway, a fix would be welcomed. Please also add a test for it.

🚀 Feature Proposal

https://github.com/tsconfig/bases includes the default examples for the fastify configuration. We should recommend it in our typescript documentation, and possibly use the relevant one across all of our plugins.

We'll need to predict when a slot will become free and if it is convenient to spawn a new socket or wait for one to become free. We would need to keep track the interval between two consecutive requests and how long it will take to serve them (ideally with hdr-histogram). We can then use the poisson distribution to model those phenomenons. Then use some math based on probability to compute a decision where to create a new socket or wait for one to become free. The whole algorithm must be incredibly fast, otherwise it would negate any benefits.

sure. I don't 100% understand the problem, but +1

As titled

Nice, as supposed it worked! Now it would be nice to know why it was missing in the first place. Any clouds @mcollina ?

No idea. The above code is exactly doing what desm is doing. See

https://github.com/mcollina/desm/blob/master/index.js

Can you please send a PR? I don't really understand the difference between that and what is in the repo.

I imagine the change to alter https://github.com/mcollina/fastify-gql/blob/60ef01f8ce82522403e6088c7dabd71e9d293bdc/lib/subscriber.js#L10 so that it calls itself multiple times for all the topics. An end user can quickly implement it as well with a Promise.all.

As titled

This fixes #890; see that issue for discussion.

#754 added a very useful logger.setBindings() method. But this doesn't play well with prettifiers, which appear to make use of a cached version of the bindings:

> let child=logger.child({foo: 123});

// pino.parsedChindings is undefined at start
> child.bindings()
{ foo: 123 }
> child[Pino.symbols.parsedChindingsSym]
undefined

// when the first log call is made, pino.parsedChindings gets populated
> child.info('hello')
[2020-08-11 23:12:27.349 +0000] INFO : hello
    foo: 123
> child[Pino.symbols.parsedChindingsSym]
{ pid: 16561, hostname: 'nutrimatic', foo: 123 }

// logger.setBindings doesn't update pino.parsedChindings
> child.setBindings({bar: 456})
> child.bindings()
{ foo: 123, bar: 456 }
> child[Pino.symbols.parsedChindingsSym]
{ pid: 16561, hostname: 'nutrimatic', foo: 123 }

// so subsequent logs don't include the new bindings
> child.info('hello')
[2020-08-11 23:13:24.553 +0000] INFO : hello
    foo: 123
> child[Pino.symbols.parsedChindingsSym]
{ pid: 16561, hostname: 'nutrimatic', foo: 123 }

// manually clearing pino.parsedChindings causes it to be regenerated on the next log call
> delete child[Pino.symbols.parsedChindingsSym]
> child.info('hello')
[2020-08-11 23:14:28.240 +0000] INFO : hello
    foo: 123
    bar: 456
> child[Pino.symbols.parsedChindingsSym]
{ pid: 16561, hostname: 'nutrimatic', foo: 123, bar: 456 }

Would it be "safe" (performance-wise) to have logger.setBindings() automatically clear pino.parserChindings so that the next log call causes it to update? I think this may be OK since said updating only happens when a prettifier is enabled, so it won't impact production situations where there's no prettifier. Alternatively, could we add an additional method that manually clears pino.parserChindings?

I can submit a PR for either of these approaches; I'm just not sure which is best.

Maybe it should be documented, anyway this PR does not add it.

Yes, something like client.on('drain', onDrain(this))

you don't need it, it is this in the function (if you remove the arrow).

Fixes: https://github.com/fastify/fastify/issues/2403 The issue was because dynamic import in Typescript always imports an object that have .default property instead of assigning the default export to "top" level. In fact the compiler outputs this JS

fastify.register(Promise.resolve().then(() => __importStar(require("fastify-formbody"))));

for this ts

fastify.register(import("fastify-formbody"));

It compiles it like this because import() is implemented using require() and promises.

This PR works thanks to https://github.com/fastify/avvio/blob/76f83492819c0cbc64e6a255e92df11fe4f094fb/plugin.js#L245 that works if an object with .default property is passed.

Checklist

• [x] run npm run test and npm run benchmark
• [x] tests and/or benchmarks are included
• [ ] documentation is changed or added
• [x] commit message and code follows the Developer's Certification of Origin and the Code of conduct

🐛 Bug Report

To Reproduce

Pick any Fastify plugin (I'll use fastify-formbody for now):

fastify().register(import('fastify-formbody'));

TypeScript compiler gives the following error:

No overload matches this call.
  Overload 1 of 3, '(plugin: FastifyPluginCallback<FastifyPluginOptions>, opts?: FastifyRegisterOptions<FastifyPluginOptions>): FastifyInstance<...> & PromiseLike<...>', gave the following error.
    Argument of type 'Promise<typeof import(".../node_modules/fastify-formbody/formbody")>' is not assignable to parameter of type 'FastifyPluginCallback<FastifyPluginOptions>'.
      Type 'Promise<typeof import(".../node_modules/fastify-formbody/formbody")>' provides no match for the signature '(instance: FastifyInstance<RawServerBase, IncomingMessage | Http2ServerRequest, ServerResponse | Http2ServerResponse, FastifyLoggerInstance>, opts: FastifyPluginOptions, next: (err?: Error) => void): void'.
  Overload 2 of 3, '(plugin: FastifyPluginAsync<FastifyPluginOptions>, opts?: FastifyRegisterOptions<FastifyPluginOptions>): FastifyInstance<...> & PromiseLike<...>', gave the following error.
    Argument of type 'Promise<typeof import(".../node_modules/fastify-formbody/formbody")>' is not assignable to parameter of type 'FastifyPluginAsync<FastifyPluginOptions>'.
      Type 'Promise<typeof import(".../node_modules/fastify-formbody/formbody")>' provides no match for the signature '(instance: FastifyInstance<RawServerBase, IncomingMessage | Http2ServerRequest, ServerResponse | Http2ServerResponse, FastifyLoggerInstance>, opts: FastifyPluginOptions): Promise<...>'.
  Overload 3 of 3, '(plugin: FastifyPluginCallback<FastifyPluginOptions> | FastifyPluginAsync<FastifyPluginOptions>, opts?: FastifyRegisterOptions<...>): FastifyInstance<...> & PromiseLike<...>', gave the following error.
    Argument of type 'Promise<typeof import(".../node_modules/fastify-formbody/formbody")>' is not assignable to parameter of type 'FastifyPluginCallback<FastifyPluginOptions> | FastifyPluginAsync<FastifyPluginOptions>'.
      Type 'Promise<typeof import(".../node_modules/fastify-formbody/formbody")>' is not assignable to type 'FastifyPluginAsync<FastifyPluginOptions>'.

Expected behavior

There should be no errors.

We can use as any to bypass this problem but not sure it's the best thing to do.

Your Environment

• node version: 14
• fastify version: 3.0.1
• os: Mac