Skip to content

Tricky error related to 500 error pages #910

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

Closed
javiereguiluz opened this issue Dec 5, 2018 · 9 comments · Fixed by symfony/webpack-encore-bundle#74
Closed

Tricky error related to 500 error pages #910

javiereguiluz opened this issue Dec 5, 2018 · 9 comments · Fixed by symfony/webpack-encore-bundle#74
Labels

Comments

@javiereguiluz
Copy link
Member

Yesterday I merged #909 as an (ugly) temporary solution to a very tricky error.

How to reproduce the error:

  • Use prod and debug=0 in .env
  • Comment the DATABASE_URL config to trigger a 500 error
  • The 500 error page sometimes is styled with CSS and sometimes isn't:
    • The 500 error for this page shows styles: /en/blog/posts/lorem-ipsum-dolor-sit-amet-consectetur-adipiscing-elit
    • The 500 error for this page doesn't: /en/blog/

Can anyone spot the reason and provide a pull request to fix it? Thanks!

@kevin-verschaeve
Copy link

kevin-verschaeve commented Dec 5, 2018

for some reason that I don't not understand either, the generated link tag is empty, event if the asset is found.

Adding, a dump, and a var_dump shows the difference, see the screenshot below and the associated code

Screenshot

bug_link_tags

Corresponding debug code
// Symfony\WebpackEncoreBundle\Asset\TagRenderer

    public function renderWebpackLinkTags(string $entryName, string $packageName = null): string
    {
        $scriptTags = [];
        foreach ($this->entrypointLookup->getCssFiles($entryName) as $filename) {
            $scriptTags[] = sprintf(
                '<link rel="stylesheet" href="%s">',
                htmlentities($this->getAssetPath($filename, $packageName))
            );

            var_dump(
                \htmlentities($this->getAssetPath($filename, $packageName)),
                sprintf(
                    '<link rel="stylesheet" href="%s">',
                    htmlentities($this->getAssetPath($filename, $packageName))
                ),
                '<link rel="stylesheet" href="/build/css/app.4aa95248.css">',
                $scriptTags
            );

            dump(
                \htmlentities($this->getAssetPath($filename, $packageName)),
                sprintf(
                    '<link rel="stylesheet" href="%s">',
                    htmlentities($this->getAssetPath($filename, $packageName))
                ),
                '<link rel="stylesheet" href="/build/css/app.4aa95248.css">',
                $scriptTags
            );
        }

        die;

        return implode('', $scriptTags);
    }

var_dump shows an "empty" string with a length of 58... (??) and dump shows the good string.
echo'ing the string provide a empty output, so no link tag is rendered, and that is the issue.

I don't understand yet, why var_dump and echo does not displays the string correctly.

If someone has already experienced something similar in the past...

@ckrack
Copy link

ckrack commented Dec 5, 2018

The reason is, that webpack-encore-bundle's EntrypointLookup already has the css file in the returnedFiles in this line:
https://github.com/symfony/webpack-encore-bundle/blob/a3382c840f74db83c3df42cd811e06934c422bd9/src/Asset/EntrypointLookup.php#L65

@ckrack
Copy link

ckrack commented Dec 5, 2018

// webpack-encore-bundle/src/Asset/EntrypointLookup.php
    public function getCssFiles(string $entryName): array
    {
+       dump('returned files:', $this->returnedFiles);
        return $this->getEntryFiles($entryName, 'css');
    }
// ...
    private function getEntryFiles(string $entryName, string $key): array
    {
        $this->validateEntryName($entryName);
        $entriesData = $this->getEntriesData();
        $entryData = $entriesData['entrypoints'][$entryName];
        if (!isset($entryData[$key])) {
            // If we don't find the file type then just send back nothing.
            return [];
        }

        // make sure to not return the same file multiple times
        $entryFiles = $entryData[$key];
+       dump('entryfiles:', $entryFiles);
+       dump('diff entry and existing returned', array_diff($entryFiles, $this->returnedFiles));
        $newFiles = array_values(array_diff($entryFiles, $this->returnedFiles));
        $this->returnedFiles = array_merge($this->returnedFiles, $newFiles);
+       dump('wrote returned files');
+       dump('newfiles', $newFiles);
        return $newFiles;
    }

Output from calling /en/blog/

"returned files:"
array:1 [
  0 => "/build/css/app.4aa95248.css"
]
"entryfiles:"
array:1 [
  0 => "/build/css/app.4aa95248.css"
]
"diff entry and existing returned"
[]
"wrote returned files"
"newfiles"
[]

Output from calling: /en/blog/posts/lorem-ipsum-dolor-sit-amet-consectetur-adipiscing-elit

"returned files:"
[]
"entryfiles:"
array:1 [▼
  0 => "/build/css/app.4aa95248.css"
]
"diff entry and existing returned"
array:1 [▼
  0 => "/build/css/app.4aa95248.css"
]
"wrote returned files"
"newfiles"
array:1 [▼
  0 => "/build/css/app.4aa95248.css"
]

The difference is the empty vs non-empty array in the first dump.

@MatthieuBraure
Copy link

On /en/blog/posts/lorem-ipsum-dolor-sit-amet-consectetur-adipiscing-elit, we get an immediate exception (TableNotFoundException) due to ParamConverter, so EntrypointLookup is fresh and we get the wanted css.

On /en/blog, index is load without error, so EntryLookup fill $returnedFiles as expected; then error is thrown when really loading $post (in for loop in twig). So another request is 'launched' to handle the TwigError but we stay in the same context, with the returnedFiles previously load.

Not sure how to fix that though.

@MatthieuBraure
Copy link

Maybe webpack-encore can add an exception listener to call the reset method ?

@sstok
Copy link

sstok commented Dec 5, 2018

Ah, so the problem is that Symfony loads page with the CSS, but then a sub-request is started for the Exception which doesn't have the CSS as this was part of the main page.

Good catch folks 👍

@weaverryan
Copy link
Member

You guys nailed it. I’m also not sure what the best fix is. We could reset in an e caption listener... but more abstractly, if you make a sub-request that returns a full HTML page (yes, that’s uncommon outside of error pages but possible), shouldn’t the entry files cache used for that sub-request be different than the entry files cache used on the master request?

@ckrack
Copy link

ckrack commented Dec 5, 2018

You guys nailed it. I’m also not sure what the best fix is. We could reset in an e caption listener... but more abstractly, if you make a sub-request that returns a full HTML page (yes, that’s uncommon outside of error pages but possible), shouldn’t the entry files cache used for that sub-request be different than the entry files cache used on the master request?

This is what i had in mind in my fix.
I think it might have an issue though - it resets for all sub-requests, not only when they return full html.
So when a sub-request returns only partial html, but wants to output an additional asset in there, due to the reset all assets of the type would be output again.

weaverryan added a commit to symfony/webpack-encore-bundle that referenced this issue Jan 31, 2020
…(tbmatuka)

This PR was squashed before being merged into the master branch (closes #74).

Discussion
----------

Reset default EntrypointLookup on exception to fix #21 and #73

Since @ckrack seems to be unavailable to continue working on #21, I figured this would be faster :)

I don't like having `_default` hardcoded in the listener, but I see no other options right now.
I thought about adding a `resetAll()` method to EntrypointLookupCollection, but there were a couple of issues with that:
1. It would either be a BC break if I added it to the interface, or an important method that isn't interfaced and I don't really like either of those.
2. I couldn't even implement it because the container that we get in the collection only has `has()` and `get()` methods, so I couldn't go through it. This would also have to be replaced (and break BC) to implement `resetAll()`.

Fixes symfony/demo#910

Commits
-------

da36629 Reset default EntrypointLookup on exception to fix #21 and #73
@javiereguiluz
Copy link
Member Author

Let's close this old and edge-case issue. I haven't faced it since I reported it or I wasn't aware of facing the issue, so it's not important anymore. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
6 participants