fix: set Blobs context on the process #6284
Conversation
📊 Benchmark resultsComparing with 42c8805
|
| @@ -8,6 +9,8 @@ import { getPathInProject } from '../settings.js' | |||
|
|
|||
| let hasPrintedLocalBlobsNotice = false | |||
|
|
|||
| export const BLOBS_CONTEXT_VARIABLE = 'NETLIFY_BLOBS_CONTEXT' | |||
There was a problem hiding this comment.
Ideally @netlify/blobs should export this.
There was a problem hiding this comment.
Code looks good. Could we add a test for this? Here's an example for how the framework server test could look: https://github.com/netlify/cli/pull/6226/files#diff-c119c8fa97b1f6adc793b45e9b5cd627da0ea828513cfbf8444eba89c2312839
| // be available to the Lambda. This would be inconsistent with production | ||
| // where only V2 functions get the context injected. To fix it, unset the | ||
| // context variable before invoking the function. | ||
| [BLOBS_CONTEXT_VARIABLE]: undefined, |
There was a problem hiding this comment.
Looking at the implementation of this, it seems like it mutates process.env:
This leads to weird side-effects, like the env variable vanishing upon the first V1 Function execution. In this specific instance, it's probably alright because the framework child process was started earlier, and because V2 Functions don't rely on this env variable. But might be worth adding a comment.
Great call. Can I do it as a follow-up once your PR is merged so that I can make it part of your test? Integration tests are a bit expensive so reusing one here would be beneficial, I think. |
|
Sounds good, yeah! |
|
Nice! Going to approve, what's your thoughts on #6284 (comment)? |
Summary
To make Blobs available in Netlify Dev, we're currently relying on the functions bootstrap layer to receive the data in the event and populate the context environment variable. This follows what happens in production.
However, there are situations where a framework's own dev server will handle requests instead of the CLI server, and the Blobs context will not be available there because requests aren't flowing through our bootstrap layer.
When deployed, that framework code will be translated to a Netlify Function, where the context will be available, so the fact that it's not available in the CLI is an inconsistency.
With this PR, CLI takes over the responsibility of setting the Blobs context, which it does by setting the environment variable on the parent process, which means framework servers will get access to it.
To maximise parity with production, we hide the context from any functions in the Lambda compatibility mode (aka a v1 function), where the context is not available in production.
The only situation where we will have inconsistencies is if a framework generates a v1 function, since the context will now be available locally but not in production. There's not much we can do to detect this situation, though.