10 lines
1.8 KiB
Markdown
10 lines
1.8 KiB
Markdown
# Private drafts across account switching
|
|
|
|
WJ-042 starts with Alice's unsaved work draft in the real Chromium UI. Alice creates an invitation through the admin page, signs out through Settings, and Bob registers with that invitation using captured email through the login forms in the same browser. Neither account nor login cookies are injected by the fixture.
|
|
|
|
Bob's new-work form must have empty hours and description and no recovery buttons. The same checks are repeated after closing the page and opening a new tab. Bob then signs out and Alice signs in again: her form must also have no earlier draft. This final return distinguishes actual removal from owner-specific filtering alone. Work and mutation tables must remain empty throughout.
|
|
|
|
The server, browser context, database and captured mail are test-owned. No production data or real email is used. Validation passed for 0.1.43-SNAPSHOT: all six browser scenarios and the targeted lock-order regression; full local CI reports 195 JVM cases, 180 executed, 15 pending acceptance cases skipped, zero failures/errors, 68 operations tests, 17 frontend tests and passing production/admin-recovery smoke checks.
|
|
|
|
The first browser run exposed a real lock-order deadlock while initializing Bob's dashboard. DeviceLoginService.resolve used a joined FOR UPDATE that could lock DEVICE_LOGIN before APP_USER, whereas owner transactions lock APP_USER first and may resolve identity again. Resolution now reads the candidate account, locks and checks that account, then locks and revalidates the device token and expiry. The candidate read alone never grants access. The regression test holds an account transaction, observes the competing resolver's actual H2 lock wait, and resolves inside the owner transaction before releasing it. Both requests must complete successfully. No schema migration is needed.
|