Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix missing await of params when metadata with an image file pt2 #74193

Merged
merged 1 commit into from
Jan 15, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion crates/next-core/src/app_page_loader_tree.rs
Original file line number Diff line number Diff line change
Expand Up @@ -250,7 +250,7 @@ impl AppPageLoaderTreeBuilder {
let metadata_route = &*get_metadata_route_name((*item).into()).await?;
writeln!(
self.loader_tree_code,
"{s} url: fillMetadataSegment({}, props.params, {}) + \
"{s} url: fillMetadataSegment({}, await props.params, {}) + \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems safe since we mark the function as async on L244. Would still be nice to get confirmation from @huozhi that we currently test this codepath.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The metadata tests are currently not run with dynamicIO yet as there're still some untackled issues yet. But ideally we want to do that later.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this codepath only hit with dynamic I/O? I'm not too concerned with fixing the warning since that's fairly obvious. What's not obvious is that await is actually in an async function so I want to make sure we have some smoke test.

Or you feel confident to merge this without a test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the generated code, for the code path that triggered the bug on my project, it is indeed in an async function cf
#74193 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what I understand the async keyword is coming from this line

writeln!(self.loader_tree_code, "{s}(async (props) => [{{")?;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@huozhi @eps1lon Can I run a test or help write a test to ensure it will not cause any issue ?
If so can you point me in the right direction ? I do not know where would be the right place to start.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's fine to merge now as the webpack loader side was also updated before with the same logic. we can follow up the testing later

`?${{{identifier}.src.split(\"/\").splice(-1)[0]}}`,",
StringifyJs(&pathname_prefix),
StringifyJs(metadata_route),
Expand Down
Loading