[Bug?]: Page does not open after 1.1.5>1.1.6 upgrade

[x2d7751347m]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Current behavior 😯

503 Server Unavailable
Error: Cannot find any path matching /.
    at createError (file:///C:/[my_filesystem_location]/node_modules/.pnpm/h3@1.15.3/node_modules/h3/dist/index.mjs:71:15)
    at file:///C:/[my_filesystem_location]/node_modules/.pnpm/h3@1.15.3/node_modules/h3/dist/index.mjs:2027:13
    at async Object.callAsync (file:///C:/[my_filesystem_location]/node_modules/.pnpm/unctx@2.4.1/node_modules/unctx/dist/index.mjs:72:16)
    at async Server.toNodeHandle (file:///C:/[my_filesystem_location]/node_modules/.pnpm/h3@1.15.3/node_modules/h3/dist/index.mjs:2295:7)

Check console logs for more information.

Expected behavior 🤔

The page I created should show up.

Steps to reproduce 🕹

Steps:

1. pnpm dev
2. Enter my URL on browser.

Context 🔦

When I tried all the paths/pages in the site

All pages under src/routes are inaccessible, such as index.tsx, (main)/login.tsx, etc. ex)https://false_domain.com/, https://false_domain.com/login,
https://false_domain.com/some_path/bluh

Top-level folders/files are accessible (downloaded) except /src.
ex)https://false_domain.com/public/favicon.ico, https://false_domain.com/excel/excel_exam.xlsx

This is caused by changing only the version of Solid Start from 1.1.5 to 1.1.6 without changing all other libraries.

Your environment 🌎

System:
  OS: Windows 11
app.config.ts:


export default defineConfig({
    middleware: "./src/middleware.ts",
    server: {
        preset: 'node-server',
        rollupConfig: {
            external: ['__STATIC_CONTENT_MANIFEST', 'node:async_hooks'],
        },
        https: {
            key: './location/privkey.pem',
            cert: './location/cert.crt',
        },
        prerender: {
            routes: ["/dashboard", "/auth/login"]
        },
        analyze: {filename: 'visualizeBundle.html'},
    },
    solid: {
        babel: {
            plugins: [
                ["@babel/plugin-proposal-optional-chaining-assign", {version: "2023-07"}]
            ],
            env: {
                development: {
                    compact: true
                },
            }
        }
    },
    vite: {
        plugins: [suidPlugin(),
        ],
        build: {
            target: "esnext",
            sourcemap: process.env.NODE_ENV === 'development'
        },
        server: { https: true },
    },
});

tsconfig.json:

{
  "compilerOptions": {
    "strict": true,
    "target": "ESNext",
    "module": "ESNext",
    "moduleResolution": "bundler",
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "jsx": "preserve",
    "jsxImportSource": "solid-js",
    "allowJs": true,
    "types": [
      "vinxi/types/client"
    ],
    "noEmit": true,
    "isolatedModules": true,
    "paths": {
      "~/*": [
        "./src/*"
      ]
    }
  }
}

package.json:

// package.json
{
  "type": "module",
  "name": "project_name",
  "version": "0.0.1",
  "description": "",
  "scripts": {
    "dev": "vinxi dev --host",
    "build": "vinxi build",
    "start": "vinxi start",
    "protos": "powershell -File generate-protos.ps1",
    "postbuild": "node post-build.js"
  },
  "license": "MIT",
  "devDependencies": {
    "@protobuf-ts/plugin": "^2.11.1",
    "@protobuf-ts/protoc": "^2.11.1",
    "@protobuf-ts/runtime": "^2.11.1",
    "@tailwindcss/forms": "^0.5.10",
    "@tailwindcss/postcss": "^4.1.11",
    "@types/google-protobuf": "^3.15.12",
    "autoprefixer": "^10.4.21",
    "postcss": "^8.5.6",
    "tailwindcss": "^4.1.11",
    "typescript": "^5.8.3",
    "vite": "^6.3.5",
    "vite-plugin-solid-svg": "^0.8.1"
  },
  "dependencies": {
    "@babel/plugin-proposal-optional-chaining-assign": "^7.27.1",
    "@fontsource/inter": "^5.2.6",
    "@kobalte/core": "^0.13.10",
    "@modular-forms/solid": "^0.25.1",
    "@mui/material": "^7.2.0",
    "@mui/system": "^7.2.0",
    "@protobuf-ts/runtime-rpc": "^2.11.1",
    "@rnwonder/solid-date-picker": "^1.4.7",
    "@solid-primitives/event-listener": "^2.4.3",
    "@solid-primitives/immutable": "^1.1.2",
    "@solid-primitives/scheduled": "^1.5.2",
    "@solid-primitives/utils": "^6.3.2",
    "@solidjs/meta": "^0.29.4",
    "@solidjs/router": "^0.15.3",
    "@solidjs/start": "1.1.6",
    "@suid/icons-material": "^0.8.1",
    "@suid/material": "^0.18.0",
    "@suid/system": "^0.13.0",
    "@suid/vite-plugin": "^0.3.1",
    "@tailwindcss/vite": "^4.1.11",
    "@types/papaparse": "^5.3.16",
    "@valibot/i18n": "^1.0.0",
    "ag-grid-community": "^33.3.2",
    "class-variance-authority": "^0.7.1",
    "clsx": "^2.1.1",
    "date-fns": "^4.1.0",
    "exceljs": "^4.4.0",
    "immer": "^10.1.1",
    "ky": "^1.8.1",
    "moment": "^2.30.1",
    "rambda": "^10.3.0",
    "solid-ag-grid": "^0.0.230",
    "solid-icons": "^1.1.0",
    "solid-js": "^1.9.7",
    "tailwind-merge": "^3.3.1",
    "tailwindcss-animate": "^1.0.7",
    "tw-animate-css": "^1.3.5",
    "valibot": "^1.1.0",
    "vinxi": "^0.5.8",
    "vite-plugin-solid": "^2.11.7",
    "vite-tsconfig-paths": "^5.1.4"
  },
  "pnpm": {
    "onlyBuiltDependencies": [
      "esbuild"
    ]
  }
}

[brenelz]

Are you able to setup a minimal reproducer repo that showcases the issue?

[x2d7751347m]

Are you able to setup a minimal reproducer repo that showcases the issue?

https://github.com/x2d7751347m/solid-start-1.1.6-bug-issue-1920/tree/1.1.5
https://github.com/x2d7751347m/solid-start-1.1.6-bug-issue-1920/tree/1.1.6

Default url: https://localhost:3000/

Here is the repo
You'll probably need to register a local certification (SSL) on your device.

[huseeiin]

which routes are inaccessible? and are they API routes?

[x2d7751347m]

which routes are inaccessible? and are they API routes?

Every route.
If you enter the root path, it will automatically redirect you to login page. You can also see the possible routes in src/routes.
If you run 1.1.5/1.1.6 and connect to the domain, 1.1.5 will open the page, while 1.1.6 will not find the page.

[huseeiin]

Are you able to setup a minimal reproducer repo that showcases the issue?

which routes are inaccessible? and are they API routes?

Every route. If you enter the root path, it will automatically redirect you to login page. You can also see the possible routes in src/routes.

this is caused by a PR by me. i apologize. what the PR does is when an API route is found, it returns undefined if it didn't return any response (which is why you see the 404 page). it shouldn't apply to normal pages. is your index route (/) a page or an API route?

[x2d7751347m]

Are you able to setup a minimal reproducer repo that showcases the issue?

which routes are inaccessible? and are they API routes?

Every route. If you enter the root path, it will automatically redirect you to login page. You can also see the possible routes in src/routes.

this is caused by a PR by me. i apologize. what the PR does is when an API route is found, it returns undefined if it didn't return any response (which is why you see the 404 page). it shouldn't apply to normal pages. is your index route (/) a page or an API route?

This is a regular page, not an API path.
Path from content root : src/routes/(main)/index.tsx

// intex.tsx
import {type RouteSectionProps} from "@solidjs/router";


export default function (props: RouteSectionProps) {
    return (
        <div></div>
    );
}

Not only is the root path not recognized, but also any page such as /auth/login, /auth/test (which does not require authentication), or /dashboard (which redirects to the login page if there is no authentication).

[huseeiin]

i discovered the issue. its because your [...404].tsx route contains both GET and default exports and its being treated as an API route.

[huseeiin]

@brenelz do you think we should just revert #1912 ? is it intended that pages can also export GET and methods to act like middleware?

[x2d7751347m]

i discovered the issue. its because your [...404].tsx route contains both GET and default exports and its being treated as an API route.

I understand.
In general, I can split them out over different routes rather than forcing them into one.
Still, for intentional attacks like GET requests that are easily exploitable, it would be more efficient than serving the whole page.

I want the maintainer to consider that similar extensibility can be limiting.