Repository navigation
refactor(deploy): simplify code post type fixes - #8626
Conversation
|
Important Review skippedReview was skipped as selected files did not have any reviewable changes. ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Summary
Merge Risk: ⚪ Minimal · up to
|
📊 Benchmark resultsComparing with 00a2677
|
commit: |
978ca56 to
9f36ceb
Compare
Batch 2 of 3 of follow-ups to #8599 (batch 1 here: #8605). Out of an abundance of caution, that PR was kept purely focused on type changes. - Drop runtime checks for options the types now require - Remove the unused `assetType` option from file hashing - Only upload in-memory bodies for static files - Every upload built its body with `body ?? fs.createReadStream(filepath)`, although only the generated `netlify.toml` (an `InlineUploadFile`) ever carries an in-memory body. Static files still upload their inline `body` when present and stream `filepath` otherwise; functions, edge functions and servers now always stream from `filepath`. - Build the functions config with `Object.fromEntries` - The per-function config payload sent to the API was accumulated with a spreading `reduce`. It is now built by a named `toFunctionConfigPayload` mapper and `Object.fromEntries`, which also gives the payload a derived type.
9f36ceb to
573165c
Compare
Batch 3 of 3 of follow-ups to #8599 ([batch 1](#8605), [batch 2](#8626)). Out of an abundance of caution, that PR was kept purely focused on type changes. - Share one poller between `waitForDiff` and `waitForDeploy` instead of duplicating code - Resolve the drop deploy poll with the ready deploy - `waitForDropDeploy` captured the ready deploy in an outer variable and returned it with a non-null assertion after polling. The poll now resolves with it directly via `pWaitFor.resolveWith`. - Rethrow the final drop upload error from inside the retry loop - The drop file upload retry loop remembered the last error, skipped the backoff on the final attempt, and threw the remembered error after the loop. It now throws directly on a permanent failure or on the last attempt, and otherwise backs off and retries. The status is read through an `instanceof Error` guard instead of a cast. - Don't return the upload promise to the backoff emitter. It wasn't used, resulting in lint errors about promise misuse.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Batch 3 of 3 of follow-ups to #8599 ([batch 1](#8605), [batch 2](#8626)). Out of an abundance of caution, that PR was kept purely focused on type changes. - Share one poller between `waitForDiff` and `waitForDeploy` instead of duplicating code - Resolve the drop deploy poll with the ready deploy - `waitForDropDeploy` captured the ready deploy in an outer variable and returned it with a non-null assertion after polling. The poll now resolves with it directly via `pWaitFor.resolveWith`. - Rethrow the final drop upload error from inside the retry loop - The drop file upload retry loop remembered the last error, skipped the backoff on the final attempt, and threw the remembered error after the loop. It now throws directly on a permanent failure or on the last attempt, and otherwise backs off and retries. The status is read through an `instanceof Error` guard instead of a cast. - Don't return the upload promise to the backoff emitter. It wasn't used, resulting in lint errors about promise misuse.
Summary
Batch 2 of 3 of follow-ups to #8599 (batch 1 here: #8605). Out of an abundance of caution, that PR was kept purely focused on type changes.
assetTypeoption from file hashingbody ?? fs.createReadStream(filepath), although only the generatednetlify.toml(anInlineUploadFile) ever carries an in-memory body. Static files still upload their inlinebodywhen present and streamfilepathotherwise; functions, edge functions and servers now always stream fromfilepath.Object.fromEntriesreduce. It is now built by a namedtoFunctionConfigPayloadmapper andObject.fromEntries, which also gives the payload a derived type.