webhooker

276 Commits 4 Branches 1 Tag

3 Commits

Include renames

Author	SHA1	Message	Date
clawbot	267d5b12f2	Escape the database path in the SQLite connection string (closes #518 ) check / check (push) Waiting to run Details SQLite reads a file: URI's path only up to the first ? or #, and decodes %XX escapes in it. With a data directory such as /srv/hooks#1, every database opened the one file /srv/hooks. The connection string is now built with url.URL, which escapes the path, and OmitHost keeps a relative path relative. Tests open databases in a directory whose name holds #, ? and %, and at a relative path, and check through PRAGMA database_list that each opened the file asked for. A handlers test comment that blamed # in the temporary directory's path is dropped, as that is no longer true. Model: opus-5-5	2026-10-13 09:30:24 +02:00
clawbot	15377f792b	Build every database's schema from embedded SQL files (closes #56 ) check / check (push) Waiting to run Details The main database, each webhook's event database and each archive file get their schema from SQL files under internal/db/migrations/, one directory per kind. Opening a file runs, in one transaction, each file that schema_migrations does not list. GORM stays for queries. AutoMigrate is gone, tests included. An event database holds only its own tables now, so the sweep that removed target rows copied into it is deleted. The association guard stays: without it a delivery write fails on the missing targets table. AutoMigrate also had GORM parse every model before a handle was shared. That is now done on its own: GORM races when two goroutines first use models that refer to each other. Model: opus-5-5	2026-10-13 06:34:05 +02:00
clawbot	bcdd4791ec	Say what a database or log target's attempt did, without a status (closes #388 ) check / check (push) Successful in 3m14s Details In the event log and on an event's page, every attempt by a `database` or `log` target read "success Status: — (no response)". Those targets make no HTTP request, so there is no response to have, and "no response" reads like a failed connection, which is what it means for an `http` target. A successful `database` attempt now reads "archived" and a successful `log` attempt "written to the log", with no status shown; a failed one keeps "failure" and its error line, also with no status. `http` and `slack` attempts are unchanged. The change is in the one shared attempt template. Model: opus-5-5	2026-10-03 02:41:17 +02:00

Author

SHA1

Message

Date

clawbot

267d5b12f2

Escape the database path in the SQLite connection string (closes #518 )

check / check (push) Waiting to run

Details

SQLite reads a file: URI's path only up to the first ? or #, and
decodes %XX escapes in it. With a data directory such as
/srv/hooks#1, every database opened the one file /srv/hooks. The
connection string is now built with url.URL, which escapes the path,
and OmitHost keeps a relative path relative.

Tests open databases in a directory whose name holds #, ? and %, and
at a relative path, and check through PRAGMA database_list that each
opened the file asked for. A handlers test comment that blamed # in
the temporary directory's path is dropped, as that is no longer true.

Model: opus-5-5

2026-10-13 09:30:24 +02:00

clawbot

15377f792b

Build every database's schema from embedded SQL files (closes #56 )

check / check (push) Waiting to run

Details

The main database, each webhook's event database and each archive file
get their schema from SQL files under internal/db/migrations/, one
directory per kind. Opening a file runs, in one transaction, each file
that schema_migrations does not list. GORM stays for queries.
AutoMigrate is gone, tests included.

An event database holds only its own tables now, so the sweep that
removed target rows copied into it is deleted. The association guard
stays: without it a delivery write fails on the missing targets table.

AutoMigrate also had GORM parse every model before a handle was shared.
That is now done on its own: GORM races when two goroutines first use
models that refer to each other.

Model: opus-5-5

2026-10-13 06:34:05 +02:00

clawbot

bcdd4791ec

Say what a database or log target's attempt did, without a status (closes #388 )

check / check (push) Successful in 3m14s

Details

In the event log and on an event's page, every attempt by a `database` or `log` target read "success  Status: — (no response)". Those targets make no HTTP request, so there is no response to have, and "no response" reads like a failed connection, which is what it means for an `http` target. A successful `database` attempt now reads "archived" and a successful `log` attempt "written to the log", with no status shown; a failed one keeps "failure" and its error line, also with no status. `http` and `slack` attempts are unchanged. The change is in the one shared attempt template.

Model: opus-5-5

2026-10-03 02:41:17 +02:00