webhooks: add User-Agent to outgoing requests
config: factorize integer parsing
Add a new GetInt() function to parse an integer value from a parsed
ini.File. Use that function instead of duplicated code.
Signed-off-by: Robin Jarry <robin@jarry.cc>
treewide: update to new multi worker dowork api
The work.Queue() implementation has changed and now allows scheduling
tasks from multiple goroutines in parallel. Also, it requires a new
argument for limiting the queue buffer size in order to apply back
pressure.
Define new configuration variables to allow tuning the queue sizes and
number of workers per service:
[mail]
# Maximum size of the outgoing email queue (default 512).
egress-queue-size = 512
[$service_name]
# Number of parallel workers per queue (default 1).
# There are multiple queues (for egress email, webhooks, etc.).
# This setting is applied on a per-queue basis.
queue-workers = 1
[webhooks]
# Maximum size of the webhooks queue (default 512).
queue-size = 512
Use these new settings to configure the queues and workers accordingly.
Fix unit tests as well.
Link: https://git.sr.ht/~sircmpwn/dowork/commit/95719cfc0118
Signed-off-by: Robin Jarry <robin@jarry.cc>
webhooks: do not crash when expire is NULL
This is currently not possible to create a webhook without an expiry
date. But the SQL database schema does not forbid it. If in the future
we would like to allow webhooks to be created without an expiry date, we
shouldn't crash when fetching them.
Check for the validity of the Expiry field before checking its value. If
it is nil, assume that the webhooks has no expiry date.
Signed-off-by: Robin Jarry <robin@jarry.cc>
webhooks: skip webhooks with expired credentials
The documentation states [1]:
> When the original authentication method becomes invalid (such as the
> expiration of or revocation of an OAuth 2.0 bearer token), the
> webhook is disabled.
However, this is currently not the case. Expired webhooks are indeed
filtered out in virtually all GraphQL queries (by means of core-go's
FilterWebhooks [2]), so users cannot see or delete them. They are _not_
filtered out upon scheduling, however. This commit fixes that.
The symptoms of this are that active webhooks may simply not be run - if
a user has both an expired and a valid, active webhook for some event,
the scheduling will retrieve both, fail on the expired one, and stop
processing, without any feedback to the user who scheduled the hooks.
This is a problem across all services, so core-go seems like the best
place to fix this.
[1]: https://man.sr.ht/graphql.md#webhook-authentication
[2]: https://git.sr.ht/~sircmpwn/core-go/tree/master/item/webhooks/config.go#L74,81
webhooks: Execute GraphQL queries synchronously
Execute GraphQL webhook queries synchronously instead of in a background
task to avoid race conditions.
Remove %e formatting verbs
%e is not valid for formatting error values:
> %e scientific notation, e.g. -1.234456e+78
Instead, use %w when using fmt.Errorf (for error wrapping) and
%v when using log.Printf (%w is not valid in that context).
(*WebhookQueue).deliverPayload: address error nit
This return does not need to be here.
webhooks: add comment clarifying field usage
webhooks: expand auth configuration
The purpose of this change is to enable internal webhooks to be
configured in GQL webhook tables. A webhook subscription now includes
the auth method field which is appropriate, which is limited to either
OAUTH2 or INTERNAL. In the former case, the previous set of fields will
be valid, and in the latter case, the NodeID field will be valid. This
will allow us to register webhook subscriptions for internal use.
webhooks: correct error case log format
webhooks: test error from delivery attempt
webhooks: refactor exec code into separate func
webhooks: initial prototype for GQL-native webhooks