-
Notifications
You must be signed in to change notification settings - Fork 86
fix(ssrServer): fastify scope resulted in hooks being called more than once #1242
Conversation
Size Change: 0 B Total Size: 712 kB ℹ️ View Unchanged
|
expect(register).toHaveBeenCalledTimes(22); | ||
expect(register.mock.calls[1][0]).toEqual(fastifySensible); | ||
expect(register.mock.calls[2][0]).toEqual(ensureCorrelationId); | ||
expect(register.mock.calls[3][0]).toEqual(fastifyCookie); | ||
expect(register.mock.calls[4][0]).toEqual(logging); | ||
expect(register.mock.calls[5][0]).toEqual(fastifyMetrics); | ||
expect(register.mock.calls[6]).toEqual([ |
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.
we should revisit these tests. just bumping the calls number does not make it obvious what should or should not be happening.
@@ -178,7 +178,7 @@ describe('Tests that require Docker setup', () => { | |||
}, | |||
}); | |||
|
|||
expect(response.status).toBe(200); | |||
expect(response.status).toBe(404); |
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.
This was only 200 because the application error caused by this bug was not setting the HTTP status and it defaulted to 200. Fixed in #1243
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.
For some more background this test did not change when we migrated from express to fastify. However, it was correct in express. The cors
express middleware does not change the HTTP status on preflight rejection and it defaults to 200. The @fastify/cors
package calls reply.callNotFound
on preflight rejection.
Description
Scopes the entire application within a top level plugin
Motivation and Context
addresses fastify/fastify-cors#290
Currently rejected preflight requests result in an error because
preHandler
is called twice making it attempt to end timers that have already ended.How Has This Been Tested?
Ran the prod sample locally and sent the following request and validated the error no longer occurred:
I also added logs to each of the handlers and tested the failing preflight before and after
before
Note that
preHandler
appears twice forreq-1
after
Types of Changes
Checklist:
What is the Impact to Developers Using One App?
No errors on preflight rejection