Revert server action optimization

[huozhi]

Reverting unused server actions optimization on 14.2 to avoid complex nested server actions failing. We're addressing the documentation updates in vercel/ai#2956

Revert #69788
Revert #69178

[ijjk]

Stats from current PR

Default Build

General

	vercel/next.js 14-2-1	vercel/next.js revert-server-actions-opt	Change
buildDuration	16.5s	14.9s	N/A
buildDurationCached	8s	6.9s	N/A
nodeModulesSize	200 MB	200 MB	N/A
nextStartRea..uration (ms)	405ms	404ms	N/A

Client Bundles (main, webpack)

	vercel/next.js 14-2-1	vercel/next.js revert-server-actions-opt	Change
1103-HASH.js gzip	31.6 kB	31.6 kB	N/A
1a9f679d-HASH.js gzip	53.7 kB	53.7 kB	N/A
335-HASH.js gzip	5.05 kB	5.05 kB	✓
7953.HASH.js gzip	181 B	181 B	✓
framework-HASH.js gzip	44.9 kB	44.9 kB	✓
main-app-HASH.js gzip	243 B	244 B	N/A
main-HASH.js gzip	32.2 kB	32.2 kB	N/A
webpack-HASH.js gzip	1.68 kB	1.68 kB	N/A
Overall change	50.1 kB	50.1 kB	✓

Legacy Client Bundles (polyfills)

	vercel/next.js 14-2-1	vercel/next.js revert-server-actions-opt	Change
polyfills-HASH.js gzip	31 kB	31 kB	✓
Overall change	31 kB	31 kB	✓

Client Pages

	vercel/next.js 14-2-1	vercel/next.js revert-server-actions-opt	Change
_app-HASH.js gzip	195 B	197 B	N/A
_error-HASH.js gzip	184 B	184 B	✓
amp-HASH.js gzip	501 B	506 B	N/A
css-HASH.js gzip	323 B	324 B	N/A
dynamic-HASH.js gzip	1.82 kB	1.82 kB	N/A
edge-ssr-HASH.js gzip	259 B	258 B	N/A
head-HASH.js gzip	350 B	352 B	N/A
hooks-HASH.js gzip	372 B	371 B	N/A
image-HASH.js gzip	4.23 kB	4.23 kB	✓
index-HASH.js gzip	259 B	258 B	N/A
link-HASH.js gzip	2.68 kB	2.68 kB	N/A
routerDirect..HASH.js gzip	316 B	315 B	N/A
script-HASH.js gzip	387 B	387 B	✓
withRouter-HASH.js gzip	311 B	310 B	N/A
1afbb74e6ecf..834.css gzip	106 B	106 B	✓
Overall change	4.9 kB	4.9 kB	✓

Client Build Manifests

	vercel/next.js 14-2-1	vercel/next.js revert-server-actions-opt	Change
_buildManifest.js gzip	483 B	483 B	✓
Overall change	483 B	483 B	✓

Rendered Page Sizes

	vercel/next.js 14-2-1	vercel/next.js revert-server-actions-opt	Change
index.html gzip	527 B	529 B	N/A
link.html gzip	541 B	541 B	✓
withRouter.html gzip	523 B	525 B	N/A
Overall change	541 B	541 B	✓

Edge SSR bundle Size

	vercel/next.js 14-2-1	vercel/next.js revert-server-actions-opt	Change
edge-ssr.js gzip	95.4 kB	95.4 kB	N/A
page.js gzip	3.06 kB	3.06 kB	N/A
Overall change	0 B	0 B	✓

Middleware size

	vercel/next.js 14-2-1	vercel/next.js revert-server-actions-opt	Change
middleware-b..fest.js gzip	658 B	658 B	✓
middleware-r..fest.js gzip	156 B	156 B	✓
middleware.js gzip	25.5 kB	25.5 kB	N/A
edge-runtime..pack.js gzip	839 B	839 B	✓
Overall change	1.65 kB	1.65 kB	✓

Next Runtimes

	vercel/next.js 14-2-1	vercel/next.js revert-server-actions-opt	Change
app-page-exp...dev.js gzip	171 kB	171 kB	✓
app-page-exp..prod.js gzip	98 kB	98 kB	✓
app-page-tur..prod.js gzip	99.8 kB	99.8 kB	✓
app-page-tur..prod.js gzip	94 kB	94 kB	✓
app-page.run...dev.js gzip	145 kB	145 kB	✓
app-page.run..prod.js gzip	92.5 kB	92.5 kB	✓
app-route-ex...dev.js gzip	22 kB	22 kB	✓
app-route-ex..prod.js gzip	15.4 kB	15.4 kB	✓
app-route-tu..prod.js gzip	15.4 kB	15.4 kB	✓
app-route-tu..prod.js gzip	15.2 kB	15.2 kB	✓
app-route.ru...dev.js gzip	21.7 kB	21.7 kB	✓
app-route.ru..prod.js gzip	15.2 kB	15.2 kB	✓
pages-api-tu..prod.js gzip	9.58 kB	9.58 kB	✓
pages-api.ru...dev.js gzip	9.85 kB	9.85 kB	✓
pages-api.ru..prod.js gzip	9.57 kB	9.57 kB	✓
pages-turbo...prod.js gzip	22.5 kB	22.5 kB	✓
pages.runtim...dev.js gzip	23.2 kB	23.2 kB	✓
pages.runtim..prod.js gzip	22.5 kB	22.5 kB	✓
server.runti..prod.js gzip	51.5 kB	51.5 kB	✓
Overall change	954 kB	954 kB	✓

build cache

	vercel/next.js 14-2-1	vercel/next.js revert-server-actions-opt	Change
0.pack gzip	1.61 MB	1.6 MB	N/A
index.pack gzip	113 kB	113 kB	N/A
Overall change	0 B	0 B	✓

Diff details

Diff for page.js

Diff too large to display

Diff for edge-ssr.js

Diff too large to display

Commit: dfe78ad

[TheDevMinerTV]

So, the convenience of not having to split a file is more important than the security of not leaking actions?

[huozhi]

@TheDevMinerTV We'll investigate another solution and will fix on canary first, once it's stable we can backport again. On the other side we give better error messaging so they users can get hint to split the modules if possible, and documentation to improve the existign examples.

[TheDevMinerTV]

I'd rather have the convenience of it just working securely as expected instead of getting compiler warnings / errors for actions. Just disable top-level magic strings.

(or, y'know, remove the magic strings entirely and replace it with a function that you pass your own action functions into).

[FairyPenguin]

@TheDevMinerTV We'll investigate another solution and will fix on canary first, once it's stable we can backport again. On the other side we give better error messaging so they users can get hint to split the modules if possible, and documentation to improve the existign examples.

This a very strange logic ! so while you are "investigate another solution" it was better to leave the fix for now and when there is a better stable solution replace the existing with the new one! Not remove the fix at all and leave a security issue just because it's not the optimal solution, And "better error messaging" is not a solution for a security issue.

God help us if this is the main mindset for every action in this framework.

I still remember the answer to the slowest ever dev server that it's the users problem not nextjs!

[controversial]

@FairyPenguin An incorrect implementation of tree-shaking server actions caused breaking changes in production apps on a semver-patch release.

The “security issue” of “leaking” actions is really a developer experience issue, where users misunderstand the documented behavior of server actions (to create an endpoint for functions that are exported from a file explicitly marked for server actions).

DX improvements to prevent footguns are a “nice to have,” and cannot come at the cost of production-breaking framework bugs, which is why this feature was reverted. @huozhi has said the team intends to work on bringing the feature back once there’s time to implement it without unexpected breaking changes, which is the correct approach.

In the meantime, if the security model of your app depends on explicitly creating endpoints which you never use and which must never be called, you should either (1) pin [email protected] or (2) refactor your app to avoid exposing insecure endpoints without depending on tree shaking. Being rude to hard-working OSS framework authors is not a solution.

[FairyPenguin]

@FairyPenguin An incorrect implementation of tree-shaking server actions caused breaking changes in production apps on a semver-patch release.

The “security issue” of “leaking” actions is really a developer experience issue, where users misunderstand the documented behavior of server actions (to create an endpoint for functions that are exported from a file explicitly marked for server actions).

DX improvements to prevent footguns are a “nice to have,” and cannot come at the cost of production-breaking framework bugs, which is why this feature was reverted. @huozhi has said the team intends to work on bringing the feature back once there’s time to implement it without unexpected breaking changes, which is the correct approach.

In the meantime, if the security model of your app depends on explicitly creating endpoints which you never use and which must never be called, you should either (1) pin [email protected] or (2) refactor your app to avoid exposing insecure endpoints without depending on tree shaking. Being rude to hard-working OSS framework authors is not a solution.

You are not embarrassed of yourself ?!!

Your reply needs not just to be a screenshot for learning how to do every logical fallacy and manipulate the words of others and finally play the victim but it's a lesson for how much far people can go behind the words of contributor and opensource to justify the right from the wrong and enforce a lie and wrong technical decisions in a very clear situation that doesn't need any Justifications, fabrications, and twisting and turning!

When there was a memory leak in framework and many dev includes me reported that and you replied no no no memory leak and at the end turns there is a memory leak and was fixed !! and the slowness of the dev server and i lost count !!

If you are not embarrassing yourself you need to take care of your mental health very well.

[STNeto1]

The problem could have been solved long time ago if they acknowledged the issue before hand, not acting like was a quirk and not a security issue. When the main issue first appeared, took weeks and clout for it to be really seen, ack'd and fixed. Now reverting back to a known issue just because "the dx of the other app" is worse is such a weird move.

[FairyPenguin]

The problem could have been solved long time ago if they acknowledged the issue before hand, not acting like was a quirk and not a security issue. When the main issue first appeared, took weeks and clout for it to be really seen, ack'd and fixed. Now reverting back to a known issue just because "the dx of the other app" is worse is such a weird move.

This happened exactly in every issue was reported i lost the count

1- The memory leak issue

2- the slow dev server

3- the problem with sharp

4- the server actions

...... I really can't remember how many times it the same attitude and playing the victim and blame the developers for each wrong technical decision they made or an issue appears.

[STNeto1]

@FairyPenguin An incorrect implementation of tree-shaking server actions caused breaking changes in production apps on a semver-patch release.

The “security issue” of “leaking” actions is really a developer experience issue, where users misunderstand the documented behavior of server actions (to create an endpoint for functions that are exported from a file explicitly marked for server actions).

DX improvements to prevent footguns are a “nice to have,” and cannot come at the cost of production-breaking framework bugs, which is why this feature was reverted. @huozhi has said the team intends to work on bringing the feature back once there’s time to implement it without unexpected breaking changes, which is the correct approach.

In the meantime, if the security model of your app depends on explicitly creating endpoints which you never use and which must never be called, you should either (1) pin [email protected] or (2) refactor your app to avoid exposing insecure endpoints without depending on tree shaking. Being rude to hard-working OSS framework authors is not a solution.

"The “security issue” of “leaking” actions is really a developer experience issue"

The first paragraph from Authentication and authorization says:
"You should treat Server Actions as you would public-facing API endpoints, and ensure that the user is authorized to perform the action. For example:"

The root issue lies on the fact that every async function exported from the file with top level use server , but that's nowere to be found on the page. "You should treat Server Actions as you would public-facing API endpoints" because everything is exported, be used or not, and the even crazier part is that easily findable looking at the transpiled js file.

Acting as if it wasn't an issue is just lolz.