sneak, 2026-09-29 in chat, running main under upaas on fsn1app1 (verbatim):
webhooker made a new admin password on restart instead of persisting the one from the first run. when i tried logging in with the old one, it said invalid password, when i tried the new one, i got a 500
What the code says: the admin account, and the session key, live in webhooker.db under DATA_DIR (default /var/lib/webhooker); an admin is seeded only when the database has none. A new password on restart therefore means the container started on an empty /var/lib/webhooker, i.e. the database was not on persistent storage across the redeploy (to be confirmed with sneak's upaas volume settings for the app). A new database also means a new session key, so the browser still holds session and CSRF cookies signed with the old key; the 500 on login with the new password is most likely webhooker failing on those stale cookies instead of treating them as absent.
Definition of done:
Reproduce and fix the 500: logging in with a browser that holds session or CSRF cookies from an earlier session key (or any cookie that fails to decode) behaves as a fresh visit: no 500, the stale cookies are replaced, the login works. A test covers it. If the 500 has another cause, find it (sneak's container log will show it; ask on this issue) and fix that.
Establish why the database did not survive the restart and state it here: missing or mis-pointed volume in the upaas app, the image's VOLUME or DATA_DIR handling, or anything else. If it is webhooker's, fix it; if it is upaas configuration, post the exact setting for sneak here; if upaas should have warned, file that on upaas.
On a start that creates a new database, the log says so plainly, with the database path, so an operator notices an unexpectedly empty data directory.
Model: opus-5-5
sneak, 2026-09-29 in chat, running `main` under upaas on fsn1app1 (verbatim):
> webhooker made a new admin password on restart instead of persisting the one from the first run. when i tried logging in with the old one, it said invalid password, when i tried the new one, i got a 500
What the code says: the admin account, and the session key, live in `webhooker.db` under `DATA_DIR` (default `/var/lib/webhooker`); an admin is seeded only when the database has none. A new password on restart therefore means the container started on an empty `/var/lib/webhooker`, i.e. the database was not on persistent storage across the redeploy (to be confirmed with sneak's upaas volume settings for the app). A new database also means a new session key, so the browser still holds session and CSRF cookies signed with the old key; the 500 on login with the new password is most likely webhooker failing on those stale cookies instead of treating them as absent.
Definition of done:
- Reproduce and fix the 500: logging in with a browser that holds session or CSRF cookies from an earlier session key (or any cookie that fails to decode) behaves as a fresh visit: no 500, the stale cookies are replaced, the login works. A test covers it. If the 500 has another cause, find it (sneak's container log will show it; ask on this issue) and fix that.
- Establish why the database did not survive the restart and state it here: missing or mis-pointed volume in the upaas app, the image's `VOLUME` or `DATA_DIR` handling, or anything else. If it is webhooker's, fix it; if it is upaas configuration, post the exact setting for sneak here; if upaas should have warned, file that on upaas.
- On a start that creates a new database, the log says so plainly, with the database path, so an operator notices an unexpectedly empty data directory.
Model: opus-5-5
clawbot
self-assigned this 2026-09-29 12:11:40 +02:00
Plan. The worker runs at max effort, ahead of everything else. In order:
Reproduce the 500: log in, keep the cookies, restart the app on an empty data directory, then log in with the new password while sending the old cookies.
Fix it: any cookie that fails to decode is treated as absent, and the stale cookies are replaced. A test covers it, and fails on next without the fix.
Why the database was lost: read what upaas does to a container and its volumes on restart, and what webhooker's Dockerfile does with VOLUME and DATA_DIR. The finding goes here: the exact upaas volume setting for the app if it is configuration, a fix in the same PR if webhooker is at fault, and an upaas issue if upaas should have warned.
Log a new database: a start that creates one logs it plainly, with the path.
The fix lands on next. The next to main PR then goes to sneak as merge-ready, so he can deploy it.
Model: opus-5-5
Plan. The worker runs at max effort, ahead of everything else. In order:
1. **Reproduce the 500:** log in, keep the cookies, restart the app on an empty data directory, then log in with the new password while sending the old cookies.
2. **Fix it:** any cookie that fails to decode is treated as absent, and the stale cookies are replaced. A test covers it, and fails on `next` without the fix.
3. **Why the database was lost:** read what upaas does to a container and its volumes on restart, and what webhooker's `Dockerfile` does with `VOLUME` and `DATA_DIR`. The finding goes here: the exact upaas volume setting for the app if it is configuration, a fix in the same PR if webhooker is at fault, and an upaas issue if upaas should have warned.
4. **Log a new database:** a start that creates one logs it plainly, with the path.
The fix lands on `next`. The `next` to `main` PR then goes to sneak as `merge-ready`, so he can deploy it.
Model: opus-5-5
Cause of the lost database confirmed by sneak (2026-09-29, chat): the webhook app in upaas had no volume mapped to /var/lib/webhooker, so every redeploy started on an empty data directory. That is upaas configuration, not a webhooker defect; he is adding the volume. What remains here: the 500 on login with stale cookies, and the plain log line when a start creates a new database.
Model: opus-5-5
Cause of the lost database confirmed by sneak (2026-09-29, chat): the webhook app in upaas had no volume mapped to `/var/lib/webhooker`, so every redeploy started on an empty data directory. That is upaas configuration, not a webhooker defect; he is adding the volume. What remains here: the 500 on login with stale cookies, and the plain log line when a start creates a new database.
Model: opus-5-5
Built in #362: a session cookie that no longer decodes counts as no cookie, so the new password logs in and the old cookies are replaced; a start that creates the database logs created a new, empty database at WARN with its path.
Why the database was new: upaas's Restart button keeps a container's files, but a deploy (a push to the branch the app follows, the Deploy button, or a rollback) replaces the container and keeps only the app's volumes. webhooker keeps everything in /var/lib/webhooker. With a volume there, the data would have survived, or the container would not have started at all (Docker refuses a missing host directory; the current image cannot use a root-owned one). Yours started with a new banner, so the app has no volume at /var/lib/webhooker, or DATA_DIR is set elsewhere. A VOLUME line in the image would not have kept the data: each new container would get a new, empty one.
The setting, under the app's Volumes in upaas: host path /srv/webhooker/data (or any absolute path), container path /var/lib/webhooker, not read-only; leave DATA_DIR unset. Deploys with it fail until sneak/upaas#235 (upaas creates a missing host directory) and #353 (the image makes its data directory its own) have both landed. upaas should have said that a deploy discards everything else: sneak/upaas#248.
Until then each deploy starts empty again, with a new password in docker logs upaas-webhooker; logging in from a private window avoids the 500.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/webhooker/pulls/362: a session cookie that no longer decodes counts as no cookie, so the new password logs in and the old cookies are replaced; a start that creates the database logs `created a new, empty database` at `WARN` with its path.
Why the database was new: upaas's Restart button keeps a container's files, but a deploy (a push to the branch the app follows, the Deploy button, or a rollback) replaces the container and keeps only the app's volumes. webhooker keeps everything in `/var/lib/webhooker`. With a volume there, the data would have survived, or the container would not have started at all (Docker refuses a missing host directory; the current image cannot use a root-owned one). Yours started with a new banner, so the app has no volume at `/var/lib/webhooker`, or `DATA_DIR` is set elsewhere. A `VOLUME` line in the image would not have kept the data: each new container would get a new, empty one.
The setting, under the app's Volumes in upaas: host path `/srv/webhooker/data` (or any absolute path), container path `/var/lib/webhooker`, not read-only; leave `DATA_DIR` unset. Deploys with it fail until https://git.eeqj.de/sneak/upaas/issues/235 (upaas creates a missing host directory) and https://git.eeqj.de/sneak/webhooker/pulls/353 (the image makes its data directory its own) have both landed. upaas should have said that a deploy discards everything else: https://git.eeqj.de/sneak/upaas/issues/248.
Until then each deploy starts empty again, with a new password in `docker logs upaas-webhooker`; logging in from a private window avoids the 500.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
sneak, 2026-09-29 in chat, running
mainunder upaas on fsn1app1 (verbatim):What the code says: the admin account, and the session key, live in
webhooker.dbunderDATA_DIR(default/var/lib/webhooker); an admin is seeded only when the database has none. A new password on restart therefore means the container started on an empty/var/lib/webhooker, i.e. the database was not on persistent storage across the redeploy (to be confirmed with sneak's upaas volume settings for the app). A new database also means a new session key, so the browser still holds session and CSRF cookies signed with the old key; the 500 on login with the new password is most likely webhooker failing on those stale cookies instead of treating them as absent.Definition of done:
VOLUMEorDATA_DIRhandling, or anything else. If it is webhooker's, fix it; if it is upaas configuration, post the exact setting for sneak here; if upaas should have warned, file that on upaas.Model: opus-5-5
Plan. The worker runs at max effort, ahead of everything else. In order:
nextwithout the fix.Dockerfiledoes withVOLUMEandDATA_DIR. The finding goes here: the exact upaas volume setting for the app if it is configuration, a fix in the same PR if webhooker is at fault, and an upaas issue if upaas should have warned.The fix lands on
next. ThenexttomainPR then goes to sneak asmerge-ready, so he can deploy it.Model: opus-5-5
Cause of the lost database confirmed by sneak (2026-09-29, chat): the webhook app in upaas had no volume mapped to
/var/lib/webhooker, so every redeploy started on an empty data directory. That is upaas configuration, not a webhooker defect; he is adding the volume. What remains here: the 500 on login with stale cookies, and the plain log line when a start creates a new database.Model: opus-5-5
Built in #362: a session cookie that no longer decodes counts as no cookie, so the new password logs in and the old cookies are replaced; a start that creates the database logs
created a new, empty databaseatWARNwith its path.Why the database was new: upaas's Restart button keeps a container's files, but a deploy (a push to the branch the app follows, the Deploy button, or a rollback) replaces the container and keeps only the app's volumes. webhooker keeps everything in
/var/lib/webhooker. With a volume there, the data would have survived, or the container would not have started at all (Docker refuses a missing host directory; the current image cannot use a root-owned one). Yours started with a new banner, so the app has no volume at/var/lib/webhooker, orDATA_DIRis set elsewhere. AVOLUMEline in the image would not have kept the data: each new container would get a new, empty one.The setting, under the app's Volumes in upaas: host path
/srv/webhooker/data(or any absolute path), container path/var/lib/webhooker, not read-only; leaveDATA_DIRunset. Deploys with it fail until sneak/upaas#235 (upaas creates a missing host directory) and #353 (the image makes its data directory its own) have both landed. upaas should have said that a deploy discards everything else: sneak/upaas#248.Until then each deploy starts empty again, with a new password in
docker logs upaas-webhooker; logging in from a private window avoids the 500.Model: opus-5-5