danyang-match

152 Commits 2 Branches 8 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
WorkBuddy	af5412646b	test(e2e): 运营登录只用 seed 账号；补幂等 E2E 与两处机械守卫 1) 修复一处从未暴露的 CI 缺陷库中 operator 账号没有任何迁移种子，DemoDataSeeder 也不创建运营账号（只统计数量），全新库唯一的账号来源是 seed_e2e_operators.sql。而 conftest 的 admin_token 写死 username="admin" —— 那是某台开发机上手工创建的遗留账号：本机有它所以本地一直跑绿，CI 全新库没有它 → 该 fixture 必然 401 → e2e job 从未真正通过过。同一文件里「外加迁移 seed 的 admin」这句注释也是纯粹的虚构。改用 seed 创建的 e2e_admin（已绑定 super_admin，语义等价）。 2) fixture_account_guard_test.py（2 用例）机械拦住「fixture 依赖本机手工数据」：从 seed SQL 解析账号清单，扫描 conftest 的所有登录用户名，任何一个不在 seed 内即变红；另一条锁住推理前提（迁移里确实没有 operator 种子）。两条都带「解析失败即失败」断言 —— 守卫自身静默失效是本项目反复踩过的坑。 3) idempotency_test.py（7 用例）同键重放响应逐字节相同、同键重复提交只产生一条记录、body 字段幂等未回归、不同键相互独立、同键作用域按 actor 隔离、5 线程并发同键业务恰好落库一次、无键重复 Like 不得返回 500。 4) conftest.ApiClient.call 支持 headers 覆盖，供幂等用例携带自定义键。	2026-09-18 16:37:33 +08:00
WorkBuddy	7682abd85c	fix(api): give failures real HTTP semantics; fix 401/403 confusion and CORS default Phase 23B ended with an E2E assertion changed to expect "HTTP 200 + body.code == BAD_REQUEST", documented at the time as "this project's convention". That description was accurate about the code and wrong about the intent: it described a defect, and I made the test accommodate it instead of fixing it. Auditing it found the convention was already broken, not merely risky: - ~100 sites (105, across 30 controllers) do `return ApiResponse.error(...)` / `forbidden()` / `notFound()` with no exception and no `@ResponseStatus`, so the HTTP status is always 200. Gateways and APM cannot separate 4xx from 5xx; callers cannot tell "fix your request" (400) from "don't retry" (403) from "check state first" (409) from "retry later" (429). - miniapp/utils/api.js already had 401/403/429 branches that could never be reached, since the backend never returned those codes. The concrete damage: an expired token returned 403, so `onSessionExpired` never fired and users were stuck with no way back to the login flow. - SecurityConfig had no `authenticationEntryPoint`, so Spring's default `Http403ForbiddenEntryPoint` returned 403 for unauthenticated calls, with a framework body that has no `code` field at all. - CorsConfig defaulted `allowed-origins` to `*` together with `allowCredentials(true)`, while its comment claimed "localhost only by default". Comment contradicting code is worse than no comment: it reads as safe. - Only 4 files / 15 assertions in the whole backend suite touched HTTP status, which is how this survived. Approach: one definition, two applications, zero controller changes. - ApiResponseCode gains an `httpStatus` field — the single source of truth. The constructor requires it, so a new code cannot be added without one. - GlobalExceptionHandler reads status from the enum instead of hardcoding `@ResponseStatus` per handler. - New ApiResponseStatusAdvice (ResponseBodyAdvice) fills in the status just before the body is written, covering all ~100 direct-return sites without touching them. Two constraints, both noted in code: only downgrade when the current status is still 2xx (the advice also sees exception-handler results, and must not override an already-correct 401/403/409), and never alter the body. - SecurityConfig: entry point returns 401 with a uniform ApiResponse body; access denied handler returns 403 likewise. - CorsConfig: default changed to empty (deny). Both clients are same-origin anyway — nginx proxies /api/ and Vite proxies /api — so nothing depends on it. - miniapp api.js: 401/403/429/409 branches now prefer the server's `body.message`, otherwise "账号已被封禁" would be flattened to "无权限访问". Implementation trap worth remembering: `ServerHttpResponse` has `setStatusCode` but no getter, so reading the current status requires casting to `ServletServerHttpResponse`. Verification: 37 E2E passed (33 + 4 new contract cases), including a live-stack check that a controller's direct `notFound()` now yields 404 — that path throws no exception and never reaches the exception handler, so if the advice were inactive it would silently return 200 while the enum unit tests stayed green. Backend regression 662 / 0 failures / 0 errors / 3 skipped (+6 new guards). The first regression run had 3 failures, all tests asserting the old wrong behavior (anonymous access expected 403; outsiders reading a conversation expected 200). Fixed the assertions, not the implementation. Where 404 is used instead of 403 for "invisible", that is deliberate — it prevents probing whether another user's conversation exists — and the substantive assertions (e.g. that an unauthorized response must not leak message bodies) were kept. Not done, needs a product decision: third-party credential issuance, whether rate limiting is actually active, publishing OpenAPI externally, per-caller audit and quotas, pagination/idempotency coverage, desensitization boundaries.	2026-09-18 14:34:58 +08:00
WorkBuddy	730dddde30	test(e2e): Phase 23B — rebuild E2E infrastructure; fix 6 real prod defects it exposed Phase 23 closed as PARTIAL: fake coverage was gone, but the E2E layer itself was still empty — no conftest.py anywhere, ~15 fixtures that never existed, 6 files crashing at import on os.environ["E2E_PASSWORD"], and CI never ran E2E. STATUS's "10 E2E files / ~80+ cases ✅" described files that had never executed. Infrastructure delivered: - tests/e2e/conftest.py: ApiClient (trust_env=False — a host http_proxy turns localhost calls into 502), operator_token(username) / new_user / admin_token fixtures, and a session probe that calls pytest.exit(4) when the stack is unreachable. NOT skip: skip would launder "did not run" into "passed". - pytest.ini, tests/e2e/requirements.txt, and tests/e2e/sql/ seed_e2e_operators.sql — migrations contain NO operator seed at all, so a fresh database has zero logins; the seed creates 6 e2e accounts with role bindings, idempotent, password injected via `psql -v pwd`. - CI job `e2e`: compose up -> poll /health/live (timeout = fail) -> seed -> pytest -> always teardown. Gate D-23-D is now closed. - 8 E2E files migrated off import-time env reads; tautological assertions (`x == t or not x`), a counselor token standing in for content_editor, and a bare `status_code == 200` claiming to prove INV-020 were replaced with real permission/behavior assertions. Six real production defects found only by running against real PostgreSQL (H2 has zero coverage for all of them): - D-23B-A (Critical): stale V042__add_appointment_operator_register_permission.sql left in target/classes; src had replaced it with V042__add_service_location_ announcements.sql. Packing without clean put two V042 in the jar -> Flyway "Found more than one migration with version 042" -> app would not start. Guard added: testBuildOutputHasNoDuplicateMigrationVersions scans build output (src is clean, so only this catches it). - D-23B-B (High): non-UUID path variable reached the DB -> 500 + leaked `invalid input syntax for type uuid`. Now rejected at the controller. - D-23B-C (High): 6 E2E files raised KeyError at import -> never collected. - D-23B-E (Critical): permissions = 48, role_permissions for super_admin = 18, matchmaker = 0. V015's "grant all to super_admin" was a point-in-time snapshot; the 30 permissions added later were never granted. On a fresh stack an admin cannot create a service station and matchmakers can do nothing. V044 restores super_admin to its documented definition (not an expansion); the matchmaker permission set needs a product decision and is left as a residual. - D-23B-I (Medium): IllegalArgumentException (e.g. invalid activity type) was unmapped -> 500. Now BAD_REQUEST. - D-23B-J (High): `operator does not exist: uuid = character varying` — Java ids are String, columns are uuid, PostgreSQL does not implicitly cast in comparisons. Fixed at the source with JDBC `stringtype=unspecified` (docker profile); production datasource comes from deploy env and needs the same. One judgement retracted: an initial read suggested service_appointment.register was missing. It is not — the endpoint uses service.assisted_registration, seeded in V029, and the code deliberately avoids a duplicate permission. Nothing was changed on that basis. Verification: 33 E2E passed against a live stack; unreachable stack and a missing operator password both exit 4 (never skip/pass); backend regression 656 / 0 failures / 0 errors / 3 skipped (baseline 655, +1 guard, negatively validated by injecting a duplicate V042 -> exactly one test turned red).	2026-09-18 13:50:19 +08:00

Author

SHA1

Message

Date

WorkBuddy

af5412646b

test(e2e): 运营登录只用 seed 账号；补幂等 E2E 与两处机械守卫

1) 修复一处从未暴露的 CI 缺陷

库中 operator 账号没有任何迁移种子，DemoDataSeeder 也不创建运营账号
（只统计数量），全新库唯一的账号来源是 seed_e2e_operators.sql。
而 conftest 的 admin_token 写死 username="admin" —— 那是某台开发机上
手工创建的遗留账号：本机有它所以本地一直跑绿，CI 全新库没有它 →
该 fixture 必然 401 → e2e job 从未真正通过过。
同一文件里「外加迁移 seed 的 admin」这句注释也是纯粹的虚构。

改用 seed 创建的 e2e_admin（已绑定 super_admin，语义等价）。

2) fixture_account_guard_test.py（2 用例）

机械拦住「fixture 依赖本机手工数据」：从 seed SQL 解析账号清单，
扫描 conftest 的所有登录用户名，任何一个不在 seed 内即变红；
另一条锁住推理前提（迁移里确实没有 operator 种子）。
两条都带「解析失败即失败」断言 —— 守卫自身静默失效是本项目反复踩过的坑。

3) idempotency_test.py（7 用例）

同键重放响应逐字节相同、同键重复提交只产生一条记录、body 字段幂等未回归、
不同键相互独立、同键作用域按 actor 隔离、5 线程并发同键业务恰好落库一次、
无键重复 Like 不得返回 500。

4) conftest.ApiClient.call 支持 headers 覆盖，供幂等用例携带自定义键。

2026-09-18 16:37:33 +08:00

WorkBuddy

7682abd85c

fix(api): give failures real HTTP semantics; fix 401/403 confusion and CORS default

Phase 23B ended with an E2E assertion changed to expect "HTTP 200 + body.code
== BAD_REQUEST", documented at the time as "this project's convention". That
description was accurate about the code and wrong about the intent: it described
a defect, and I made the test accommodate it instead of fixing it.

Auditing it found the convention was already broken, not merely risky:

- ~100 sites (105, across 30 controllers) do `return ApiResponse.error(...)` /
  `forbidden()` / `notFound()` with no exception and no `@ResponseStatus`, so
  the HTTP status is always 200. Gateways and APM cannot separate 4xx from 5xx;
  callers cannot tell "fix your request" (400) from "don't retry" (403) from
  "check state first" (409) from "retry later" (429).
- miniapp/utils/api.js already had 401/403/429 branches that could never be
  reached, since the backend never returned those codes. The concrete damage:
  an expired token returned 403, so `onSessionExpired` never fired and users
  were stuck with no way back to the login flow.
- SecurityConfig had no `authenticationEntryPoint`, so Spring's default
  `Http403ForbiddenEntryPoint` returned 403 for unauthenticated calls, with a
  framework body that has no `code` field at all.
- CorsConfig defaulted `allowed-origins` to `*` together with
  `allowCredentials(true)`, while its comment claimed "localhost only by
  default". Comment contradicting code is worse than no comment: it reads as
  safe.
- Only 4 files / 15 assertions in the whole backend suite touched HTTP status,
  which is how this survived.

Approach: one definition, two applications, zero controller changes.
- ApiResponseCode gains an `httpStatus` field — the single source of truth. The
  constructor requires it, so a new code cannot be added without one.
- GlobalExceptionHandler reads status from the enum instead of hardcoding
  `@ResponseStatus` per handler.
- New ApiResponseStatusAdvice (ResponseBodyAdvice) fills in the status just
  before the body is written, covering all ~100 direct-return sites without
  touching them. Two constraints, both noted in code: only downgrade when the
  current status is still 2xx (the advice also sees exception-handler results,
  and must not override an already-correct 401/403/409), and never alter the
  body.
- SecurityConfig: entry point returns 401 with a uniform ApiResponse body;
  access denied handler returns 403 likewise.
- CorsConfig: default changed to empty (deny). Both clients are same-origin
  anyway — nginx proxies /api/ and Vite proxies /api — so nothing depends on it.
- miniapp api.js: 401/403/429/409 branches now prefer the server's
  `body.message`, otherwise "账号已被封禁" would be flattened to "无权限访问".

Implementation trap worth remembering: `ServerHttpResponse` has `setStatusCode`
but no getter, so reading the current status requires casting to
`ServletServerHttpResponse`.

Verification: 37 E2E passed (33 + 4 new contract cases), including a live-stack
check that a controller's direct `notFound()` now yields 404 — that path throws
no exception and never reaches the exception handler, so if the advice were
inactive it would silently return 200 while the enum unit tests stayed green.
Backend regression 662 / 0 failures / 0 errors / 3 skipped (+6 new guards).

The first regression run had 3 failures, all tests asserting the old wrong
behavior (anonymous access expected 403; outsiders reading a conversation
expected 200). Fixed the assertions, not the implementation. Where 404 is used
instead of 403 for "invisible", that is deliberate — it prevents probing whether
another user's conversation exists — and the substantive assertions (e.g. that an
unauthorized response must not leak message bodies) were kept.

Not done, needs a product decision: third-party credential issuance, whether
rate limiting is actually active, publishing OpenAPI externally, per-caller
audit and quotas, pagination/idempotency coverage, desensitization boundaries.

2026-09-18 14:34:58 +08:00

WorkBuddy

730dddde30

test(e2e): Phase 23B — rebuild E2E infrastructure; fix 6 real prod defects it exposed

Phase 23 closed as PARTIAL: fake coverage was gone, but the E2E layer itself
was still empty — no conftest.py anywhere, ~15 fixtures that never existed,
6 files crashing at import on os.environ["E2E_PASSWORD"], and CI never ran E2E.
STATUS's "10 E2E files / ~80+ cases ✅" described files that had never executed.

Infrastructure delivered:
- tests/e2e/conftest.py: ApiClient (trust_env=False — a host http_proxy turns
  localhost calls into 502), operator_token(username) / new_user / admin_token
  fixtures, and a session probe that calls pytest.exit(4) when the stack is
  unreachable. NOT skip: skip would launder "did not run" into "passed".
- pytest.ini, tests/e2e/requirements.txt, and tests/e2e/sql/
  seed_e2e_operators.sql — migrations contain NO operator seed at all, so a
  fresh database has zero logins; the seed creates 6 e2e accounts with role
  bindings, idempotent, password injected via `psql -v pwd`.
- CI job `e2e`: compose up -> poll /health/live (timeout = fail) -> seed ->
  pytest -> always teardown. Gate D-23-D is now closed.
- 8 E2E files migrated off import-time env reads; tautological assertions
  (`x == t or not x`), a counselor token standing in for content_editor, and a
  bare `status_code == 200` claiming to prove INV-020 were replaced with real
  permission/behavior assertions.

Six real production defects found only by running against real PostgreSQL
(H2 has zero coverage for all of them):
- D-23B-A (Critical): stale V042__add_appointment_operator_register_permission.sql
  left in target/classes; src had replaced it with V042__add_service_location_
  announcements.sql. Packing without clean put two V042 in the jar -> Flyway
  "Found more than one migration with version 042" -> app would not start.
  Guard added: testBuildOutputHasNoDuplicateMigrationVersions scans build output
  (src is clean, so only this catches it).
- D-23B-B (High): non-UUID path variable reached the DB -> 500 + leaked
  `invalid input syntax for type uuid`. Now rejected at the controller.
- D-23B-C (High): 6 E2E files raised KeyError at import -> never collected.
- D-23B-E (Critical): permissions = 48, role_permissions for super_admin = 18,
  matchmaker = 0. V015's "grant all to super_admin" was a point-in-time snapshot;
  the 30 permissions added later were never granted. On a fresh stack an admin
  cannot create a service station and matchmakers can do nothing. V044 restores
  super_admin to its documented definition (not an expansion); the matchmaker
  permission set needs a product decision and is left as a residual.
- D-23B-I (Medium): IllegalArgumentException (e.g. invalid activity type) was
  unmapped -> 500. Now BAD_REQUEST.
- D-23B-J (High): `operator does not exist: uuid = character varying` — Java
  ids are String, columns are uuid, PostgreSQL does not implicitly cast in
  comparisons. Fixed at the source with JDBC `stringtype=unspecified` (docker
  profile); production datasource comes from deploy env and needs the same.

One judgement retracted: an initial read suggested service_appointment.register
was missing. It is not — the endpoint uses service.assisted_registration, seeded
in V029, and the code deliberately avoids a duplicate permission. Nothing was
changed on that basis.

Verification: 33 E2E passed against a live stack; unreachable stack and a
missing operator password both exit 4 (never skip/pass); backend regression
656 / 0 failures / 0 errors / 3 skipped (baseline 655, +1 guard, negatively
validated by injecting a duplicate V042 -> exactly one test turned red).

2026-09-18 13:50:19 +08:00