SQLite Web: gitea.db

id

Primary key. INTEGER NOT NULL

user_id

INTEGER

op_type

INTEGER

act_user_id

INTEGER

repo_id

INTEGER

comment_id

INTEGER

is_deleted

INTEGER NOT NULL (default 0

ref_name

TEXT

is_private

INTEGER NOT NULL (default 0

content

{"Commits":[{"Sha1":"2de7545076ac90e4aa88e89cdf310f72ca9692ce","Message":"fix(vm): Prisma 生成物拷到运行时真正解析的位置——旧断言查的是拷贝目标而非读取路径\n\n`pnpm vm:up` 首次真跑起整栈，api-nestjs 容器启动即崩溃重启循环：\n`@prisma/client did not initialize yet. Please run \"prisma generate\"`。\n而构建期那条\"Prisma Client 必须在部署树里\"的断言是**绿的**。\n\n根因：`pnpm deploy` 把 @prisma/client 放进\n`node_modules/.pnpm/@prisma+client@\u003chash\u003e/node_modules/`，而 @prisma/client 是相对\n**自身**去找同级 `.prisma` 的——部署树顶层那份它根本不看。上一版把生成物拷到了顶层\n扁平路径，于是：\n- 运行时解析到 .pnpm 内嵌的那份，那是 @prisma/client **自带的桩**\n  （`default.js` 第 43 行专门抛 \"did not initialize yet\"），没有 query engine；\n- 而断言 `test -d /runtime/\u003capp\u003e/node_modules/.prisma/client` 查的正是我刚拷过去的\n  顶层目录，\"往哪拷就查哪\"，必然通过。\n\n这是「断言检查的位置 ≠ 运行时读取的位置」，与 C23（typecheck 读 src、运行时读 dist）\n同型：不是断言写得弱，而是它锚在一条运行时不走的路径上。\n\n两处一起修：\n1. 拷贝目标改为 .pnpm 内嵌位置（顶层那份保留，覆盖 hoist 布局），glob 取不到即 fail。\n2. 断言改为**按运行时同一方式推导路径**（从 require.resolve('@prisma/client/package.json')\n   反推同级 .prisma），并断言 **query engine 二进制存在**——只 `test -d` 等于没查，\n   因为那个桩目录永远存在。\n\n负向测试（实跑）：去掉 .pnpm 拷贝那行后构建 EXIT=1，报\n`ERROR: no generated query engine at /runtime/api-nestjs/node_modules/.pnpm/@prisma+client@.../.prisma/client`\n——新断言会在构建期拦下这个 bug，而不是等容器启动才炸。\n\n证据（作用域＝本地工作区）：\n- pnpm vm:up 全流程通过：6 个服务全 healthy、migrate Exited(0)\n- 迁移真实应用到部署库（含 20260805120000_product_image_thumbnail /\n  20260807120000_quotation_void_and_restore）\n- 冒烟：Gateway + web + NestJS health passed；\n  Write-chain smoke passed（create + read-back under a throwaway tenant）\n- 独立复核（不依赖脚本自述）：curl 网关 /api/health -\u003e ok(db=up,redis=up)、首页 200、\n  容器内 `new PrismaClient()` 实例化成功\n- pnpm check 22 项全绿 exit=0\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-17T17:36:43-07:00"}],"HeadCommit":{"Sha1":"2de7545076ac90e4aa88e89cdf310f72ca9692ce","Message":"fix(vm): Prisma 生成物拷到运行时真正解析的位置——旧断言查的是拷贝目标而非读取路径\n\n`pnpm vm:up` 首次真跑起整栈，api-nestjs 容器启动即崩溃重启循环：\n`@prisma/client did not initialize yet. Please run \"prisma generate\"`。\n而构建期那条\"Prisma Client 必须在部署树里\"的断言是**绿的**。\n\n根因：`pnpm deploy` 把 @prisma/client 放进\n`node_modules/.pnpm/@prisma+client@\u003chash\u003e/node_modules/`，而 @prisma/client 是相对\n**自身**去找同级 `.prisma` 的——部署树顶层那份它根本不看。上一版把生成物拷到了顶层\n扁平路径，于是：\n- 运行时解析到 .pnpm 内嵌的那份，那是 @prisma/client **自带的桩**\n  （`default.js` 第 43 行专门抛 \"did not initialize yet\"），没有 query engine；\n- 而断言 `test -d /runtime/\u003capp\u003e/node_modules/.prisma/client` 查的正是我刚拷过去的\n  顶层目录，\"往哪拷就查哪\"，必然通过。\n\n这是「断言检查的位置 ≠ 运行时读取的位置」，与 C23（typecheck 读 src、运行时读 dist）\n同型：不是断言写得弱，而是它锚在一条运行时不走的路径上。\n\n两处一起修：\n1. 拷贝目标改为 .pnpm 内嵌位置（顶层那份保留，覆盖 hoist 布局），glob 取不到即 fail。\n2. 断言改为**按运行时同一方式推导路径**（从 require.resolve('@prisma/client/package.json')\n   反推同级 .prisma），并断言 **query engine 二进制存在**——只 `test -d` 等于没查，\n   因为那个桩目录永远存在。\n\n负向测试（实跑）：去掉 .pnpm 拷贝那行后构建 EXIT=1，报\n`ERROR: no generated query engine at /runtime/api-nestjs/node_modules/.pnpm/@prisma+client@.../.prisma/client`\n——新断言会在构建期拦下这个 bug，而不是等容器启动才炸。\n\n证据（作用域＝本地工作区）：\n- pnpm vm:up 全流程通过：6 个服务全 healthy、migrate Exited(0)\n- 迁移真实应用到部署库（含 20260805120000_product_image_thumbnail /\n  20260807120000_quotation_void_and_restore）\n- 冒烟：Gateway + web + NestJS health passed；\n  Write-chain smoke passed（create + read-back under a throwaway tenant）\n- 独立复核（不依赖脚本自述）：curl 网关 /api/health -\u003e ok(db=up,redis=up)、首页 200、\n  容器内 `new PrismaClient()` 实例化成功\n- pnpm check 22 项全绿 exit=0\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-17T17:36:43-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/125c54d328d3da221b5d91c0a2dd0475712c6e96...2de7545076ac90e4aa88e89cdf310f72ca9692ce","Len":1}

TEXT

created_unix

INTEGER

Update row 25166 in action