[pull] canary from vercel:canary #188
Open
+1,764,638
−310,344
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
ijjk
force-pushed
the
canary
branch
5 times, most recently
from
df8579c
to
47e5ebe
Compare
ijjk
force-pushed
the
canary
branch
3 times, most recently
from
e078ebe
to
6b863fe
Compare
In #68812 I updated most dynamic APIs to be async. One API that was not udpated was `unstable_noStore()`. This API is marked as unstable and doesn't quite fit the semantics we're exploring with dynamicIO and partial prerendering and so rather than converting it to be async we're going to deprecate it and replace it with an entirely new API. This PR doesn't actually deprecate anything yet but it does introduce `connection()`. The idea with `connection` is that you are waiting until there is a real user Request before proceeding. In the context of prerendering no Request will ever happen so the page cannot produce a static result. (this is similar to how `unstable_noStore()` works today). In a PPR context the currently rendering component won't resolve but a parent Suspense boundary can still statically render a fallback. `connect()` returns a `Promise<void>`. It is tempting to call the API `request()` and return a `Promise<Request>` however we have to guard access to the underlying Request carefully to ensure we can maximally prerender pages and to avoid confusion and maybe some frustration we are naming it `connection` since this doesn't imply a specific data set that might be returned. ``` import { connection } from 'next/server' async function MyServerComponent() { await connection() // everthing after this point will be excluded from prerendering const rand = Math.random() return <span>{rand}</span> } ```
### Fixing a bug Fix #70335 ### What? see #70335 ### Why? ### How? As for fetch standard, I think it should make filename decode with utf-8 by default https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#constructing-form-data-set <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> Co-authored-by: JJ Kasper <jj@jjsweb.site>
This test relied on `layout.js` being automatically written but that isn't the case with Turbopack (as documented). Fixed the test by adding the file that was magically generated. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
Initially the non-PPR `dynamicIO` implementation used some experimental React APIs. This change updates the technique to only depend on APIs in the canary channel and updates the packaging rules to only not opt into experimental react when dynamicIO is enabled. Other experimental flags can still opt you into experimental react such as PPR.
…70572) In the PPR navigations flow, we were always spawning a pending task for page segments, which seemed to be related to search params not updating. (x-ref: #60242) However this case doesn't seem to be necessary: the static prefetch shouldn't contain any data related to search params, as accessing search params will postpone and trigger suspense fallbacks. And when the dynamic request sends down segment key information for page segments search params, the params will be encoded in the segment key (e.g. `__PAGE__{'foo': 'bar'}`, as opposed to just `__PAGE__`. I can't think of another case where this handling would be necessary as if we are in a new tree, we'll already spawn a pending task. And if we're in the same tree, I expect the static data should be the same, while the dynamic request will contain the different data.
## What? Skips a test that checks `.babelrc` with Turbopack. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
Improve consistency by using the term that is already in use in the document. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What? Updated the documentation for `next/head` to clarify how `<title>` and `<base>` tags are handled uniquely. Specifically, the documentation states that these tags are automatically checked for duplicates by Next.js and do not require the `key` attribute. ### Why? The current documentation suggests using the `key` attribute to prevent duplicate tags in the `head`. However, `<title>` and `<base>` tags are automatically managed by the `unique` function in Next.js (`head.tsx`), ensuring only one instance is rendered without needing a `key`. This update provides clearer guidance and prevents potential misunderstandings. ### How? - Added a note explaining that `<title>` and `<base>` tags do not need a `key` attribute as they are automatically checked for duplicates by Next.js. ### Reference Source code confirming this behavior: [head.tsx#L85-L93](https://github.com/vercel/next.js/blob/3ead2d1fe98f78307861b12983c76d5a7a88c41a/packages/next/src/shared/lib/head.tsx#L84-L93) <img width="741" alt="Window" src="https://github.com/user-attachments/assets/a3a6f3fd-6aab-48a2-8d15-26df0692b0e1"> Co-authored-by: JJ Kasper <jj@jjsweb.site>
This ensures we exit the RequestStorage/PrerenderStorage context and anything else but keeps the StaticGenerationStore (which should no longer have page/request specific information). I also create new CacheStore which will be used for life/tags but for now is just used to provide a better error when cookies/headers/draftMode are accessed within the cache scope. I tried to make `React.cache` AsyncLocalStorage scope be shared between the invocation of the cached function and anything it renders later. This is also necessary in case the cached function calls Float methods like `preload()`. However, I hit issues with preserving debug info, having the right owner and that rendering a Promise in a Server Component turns it into a `React.lazy` for now which doesn't preserve the type we want. The proper solution is for React to expose a larger scope for `React.cache` and float.
…0446) Fixes #70403 ### What? When `revalidateTag()` is called directly in server components, the cache is not purged for the corresponding tags. Reproduction steps available in #70403 ### How? Check [app-render.tsx](https://github.com/vercel/next.js/compare/canary...abhi12299:fix-revalidatetag-rsc?expand=1#diff-a3e2e024db1faa1b501e0dd6040eaaf0d931cb9878ae0fb0f4c3658daa982768) This issue was introduced in #65296 in this file: [revalidate.ts](https://github.com/vercel/next.js/pull/65296/files#diff-7f0cb5bb30d44b9153d724e31c25859b9aab6cc258b35563a1d9464cd0688283). The lines removed from the file resulted in the revalidation checks to be skipped when there is an RSC request. Also fixed checks on `pendingRevalidates` to also check for `revalidatedTags`. --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>
…71042) This PR adds support for showing the original server sources of server components and server actions in the browser's developer tools. To accomplish that, we're building on top of #69190, #70563, and #70564, in which we prepared the proper generation of the source maps. This PR completes the feature, by wiring up `findSourceMapURL` (see facebook/react#30741) with a new dev server middleware that serves those source map files to the browser. Another change we had to make is disabling the dead-code elimination of server actions in client bundles (see #70103), but only in development mode. This optimization is primarily intended for production bundles, so the change should not pose a problem. With that, it's now possible to jump directly into the server sources from the browser's dev tools, e.g. for component stacks of server logs that are replayed in the browser, or when inspecting server action props in the React DevTools.
### What? show webpack/turbopack compilation duration for next build
Adjusts the styles of the prerender indicator to be smaller, and have it be expandable rather than always expanded, closer to the original behavior. This also restores the previous behavior of respecting the close preference for an hr. ### Before <details> <summary>Dark Mode</summary>  </details> <details> <summary>Light Mode</summary>  </details> ### After <details> <summary>Dark Mode</summary> https://github.com/user-attachments/assets/a60bafaa-fcf5-4d07-853c-718e12f2b8aa </details> <details> <summary>Light Mode</summary> https://github.com/user-attachments/assets/ae03eaea-fc4a-4b95-be96-85d7d13b1176 </details>
add simple versioning for persistent caching This is a temporary solution that make it correct, but not very efficient. In future we would like to have granular invalidation of the database when the Turbopack code changes. allow to disable versioning <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
### Why? Suggest React codemod if installed target Next version is >= v14.3.0-canary.45 x-ref: - Release https://github.com/vercel/next.js/releases/tag/v14.3.0-canary.45 - PR #65058  Ask user if want to stay on React 18, when using Pages Router only. 
Makes `revalidatePath` and `revalidateTag` throw if called during render. Revalidating is a side-effecting operation so it should not be allowed there. x-ref: #70642 (comment)
### What? review comments from #70945
### What? Fix logic in `NextEcmascriptClientReferenceTransition`, which does not fit for tree shaking logic. ### Why? ### How? - Closes PACK-3263
Link to tutorial video recently published: https://www.youtube.com/watch?v=sIVL4JMqRfc
The wrapper implies that the scoping of a request store is one to one with the construction of a request store. This won't be the case in the future so I've updated the with wrapper to simply be a factory function and updated callsites to call workUnitAsyncStorage.run directly. There are two sub-types of requestStore. One for page renders and one for APIs. I've updated the factories to disambiguate these cases and narrow the input arguments.
Introduces a new type of request that will be used for prefetching individual segments. Requests are issued using the Next-Router-Segment-Prefetch header. It accepts a path to the segment that is being requested. This feature part of PPR and will only be enabled when that flag is on. Because these are prefetches, segment requests are always served from the cache. They must never reach the application layer or invoke a lambda. If a matching segment is not present in the cache, the server responds with a 404 and an empty body. Segments that are fully dynamic will also 404. **In this PR, I have not yet implemented the actual segment generation**; I'm using placeholder data for now. The smoke test I added demonstrates that the placeholder data is correctly plumbed through the build, ISR, and server layers to respond to a basic request.
Co-authored-by: eps1lon <sebastian.silbermann@vercel.com>
Co-authored-by: 강동윤 (Donny) <kdy1997.dev@gmail.com>
Stacked on #71107 Scopes the request store to the render callsites within `renderToStream`. This is currently duplicative because we have an outer requestStore scope but we want to get rid of this after we remove the dependency on it from the prerender side. This just sets us up to do that in the future.
Co-authored-by: Lee Robinson <me@leerob.io>
…70467) The compilation for HMR changes often takes around 3 seconds in CI, so we need to increase the duration for the `retry` calls to avoid flakiness. [This test run](https://github.com/vercel/next.js/actions/runs/11036231635/job/30654233890) shows that it sometimes barely finishes the compilation before the timeout: <img width="467" alt="Screenshot 2024-10-11 at 19 14 41" src="https://github.com/user-attachments/assets/faae5593-3b03-4085-b3e6-54eff5c514bc"> ... and sometimes it doesn't: <img width="591" alt="Screenshot 2024-10-11 at 19 22 48" src="https://github.com/user-attachments/assets/4441b700-6c79-42dc-bdb6-abf29d7ceeec">
First PR generated by https://github.com/vercel/turbopack-resolved-vc-codemod (private repo, hacky low-quality throw-away code) <img src="https://graphite-user-uploaded-assets-prod.s3.amazonaws.com/HAZVitxRNnZz8QMiPn4a/1b2b3800-5016-44b8-8868-98c76b58823e.png" width="400"> The codemod is only able to "fix" compilation errors by rewriting function arguments as `ResolvedVc`, so it's very limited right now, but it's able to make some progress. The codemod uses ast-grep's JS API to make all the changes: https://ast-grep.github.io/guide/api-usage/js-api.html I also evaluated gritql, but it didn't seem sufficient for this codemod: [Internal discussion](https://vercel.slack.com/archives/C03EWR7LGEN/p1727755062182179?thread_ts=1727709174.550549&cid=C03EWR7LGEN) It turns out that a lot of these structs are actually dead code, so #70987 is a follow-up to delete them.
When we prerender in `dynamicIO` the async APIs that provide access to Request data return promises that never resolve. This is how we stall the prerender in that particular slot while letting the rest of the App continue. This is genernally fine however these promises can leak to other contexts via setTimeout and after. After is particularly concerning because it won't stop until the callbacks have finished and if the callback is waiting on a promise that never resolves we end up with a deadlock. To resolves this we now instrument these hanging promises with an AbortSignal. When this signal aborts the promise rejects. This works as long as the abort signal is always aborted at or after when the prerender is aborted. In this implementation's case we actually use the same abortSignal for both which provides the necessary guarantee. I believe this is fine even when we synchronously abort a render such as when you do something sync dynamic like call `Math.random()`. If it turns out that we don't want to reject immediately in these cases we can always switch to a second AbortController that is only ever aborted after the prerender is completed.
It turns out the codemod I made for #70987 is also a pretty good dead code detector, because dead code tends not to trigger any compilation errors when field types are changed 😆 Delete these structs.
…ersion (#71158) ### What? Suggest pre-released codemods by their "stable" version. ### Why? It is because if we suggest by the version range `(installed ~ target)`, pre-released codemods for the target version are not suggested when upgrading. Let's say we have a codemod for `v15.0.0-canary.x`, and we're upgrading from `v15.x` -> `v15.x`. Our initial version is higher than the codemod's version, so the codemod **will not be** suggested. This is not ideal as the codemods for pre-releases are also targeting the major version. Also, when the user attempts to run the upgrade command twice, and have installed the target version, the behavior must be **idempotent** and suggest the codemods including the pre-releases of the target version. https://github.com/user-attachments/assets/db1ab0c0-fc4e-4170-bc91-b0a096b04cef
…on target version (#71160) "is already on or higher than" is sloppy. Inform correctly to the user.
## 📚 Improving Documentation Hello, I've fixed redundant double spaces in `docs/02-app/02-api-reference/02-file-conventions/loading.mdx` and `docs/02-app/02-api-reference/02-file-conventions/route.mdx`. Co-authored-by: JJ Kasper <jj@jjsweb.site>
This just allows loading cache handler via global symbol instead of just env or `next.config`.
makes the object returned by `cookies() check if the phase we're currently in allows mutations. - `(await cookies()).set(...)` will no longer be allowed in a render that follows an action (previously, this'd work, because `actionStore.isAction` is still true during the render!) - `unstable_after(async () => (await cookies()).set(...))` will error - `const store = await cookies(); unstable_after(() => store.set(...))` will now also error this affects a couple places that mutate cookies in a way that we don't let userspace code do, like draftmode. to support this, i've added `workUnitStore.userspaceMutableCookies` and made *only that one* check for invalid accesses. that's the one we return from `cookies()` in a mutable context. the rest of the codebase can continue using `workUnitStore.mutableCookies` without worrying about phase checks.
If a request is marked as internal, we don't record fetch metrics, so we don't need to track a `fetchStart`. We're investigating cases where `performance` APIs might be unavailable in particular runtimes and can safely exclude internal requests from being subject to the possibility of it not being available.
…st (#71163) The [flakiness](https://app.datadoghq.com/ci/test-runs?query=test_level%3Atest%20env%3Aci%20%40git.repository.id%3Agithub.com%2Fvercel%2Fnext.js%20%40test.service%3Anextjs%20%40test.status%3Afail%20%40test.suite%3A%22streaming%20responses%20cancel%20inner%20stream%20after%20disconnect%22&agg_m=count&agg_m_source=base&agg_t=count¤tTab=overview&eventStack=&fromUser=false&index=citest&start=1720903715972&end=1728679715972&paused=false) of the test is underreported because due to masked errors, the test sometimes yields false-positive results. Due to a slight increase in compilation times for route handlers in #70897, the test started to fail consistently in that PR. This PR fixes the flakiness by handling the case where the request might already be aborted before the response was sent. This leads to the stream not being consumed, and subsequently its `finished` promise is never resolved, which finally leads to test timeouts.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )