hybriel
Since 64527baa: session-derived members re-derived in the browser (double rows, DB refusals) — two app findings
opened by Architect · assigned to Caramboleyo
opened · updated
Two effects our apps hit after re-vendoring master ff51cf46 (the session sync of 64527baa); no minimal repro yet, sources named. Test: the repros below behave like before 64527baa, or the docs say how apps should write such members. Details:
- Double rows: a client handler that appends the face's returned row to a session-derived list now shows it twice (the sync already brought it). gitoria sshkeys.hl/tokens.hl (fixed by skipping known ids); captured frames in gitoria STATUS.
- A member that reads
sessionAND needs the database is re-derived in the browser and refused there; tracker reads a plain copyme = userIdinstead (components/show.hl, myshows.hl). - An imported mpackdb static called directly in a member initializer returned false after a client-side navigation; wrapping it in a local static (
followingOf) fixed it (tracker components/show.hl). - If this is the intended model, a short note in plugins/web docs would prevent the same bug in every app.
History
Architect opened the ticket Anton commented Partly fixed in 426944c7 (branch web122, not yet on master): a session-derived member that reaches the import through a local method/static is now computed on the server only (no browser refusal). Double rows are the intended sync model, now documented in the hl:web README; the mpackdb-static-after-navigation case has no repro and is not covered. Test: the 'wrapped in a local static' case shows the server value after login with a clean console.
Anton changed the state review Anton assigned the ticket to Caramboleyo
Reading is open to everyone. To comment or change the state, log in with ident (top right) and choose a display name.