defintiion to have line breaks is what causes the line by line coverage
rate to drop below the threshold.
added new router test for /gotifyinfo to rectify that.
i dont know which tool added that, but now the CI seems to fail becuase
of it.
seems a bit odd that i have to commit stuff before the CI spits out
reproduceable results.
`Manager.RemoveUser` deletes from `m.instances` without holding `m.mutex`:
delete(m.instances, pluginConf.ID)
Every other access to `m.instances` is synchronized — `Instance` reads it
under `m.mutex.RLock()`, and the writes in `InitializeForUserID` /
`initializeSingleUserPlugin` happen under `m.mutex.Lock()`. The adjacent
`inst.Disable()` call in this same loop is even wrapped in Lock/Unlock, so
only the map delete is left unguarded.
`RemoveUser` is registered as the `OnUserDeleted` callback (router.go), fired
when an admin deletes a user, while any authenticated request to the plugin
API (`GET /plugin`, `/plugin/:id/*`) concurrently reads `m.instances` via
`Instance`. A `RLock` reader is not protected against a writer that never
takes the mutex, so this races and triggers Go's runtime-fatal
"concurrent map read and map write", crashing the whole server (a fatal that
gin.Recovery cannot recover). Take the write lock around the delete, matching
every other access.
Add a final safety net in redirectToChannel.SendMessage that refuses a
message when ApplicationID == 0, so it can never be stored as an orphaned
message (application_id = 0, not shown, not deletable). Requested in review.
Cover the previously untested error branches around internal-application
back-fill (create/update failures) so patch coverage no longer regresses.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
When a plugin gains the Messenger capability after it was first
initialized for a user, its plugin conf already exists without an
associated internal application (ApplicationID == 0). Messages sent by
the plugin were then stored with application_id = 0, orphaning them:
they disappeared on reload and could not be deleted (#653).
Back-fill the internal application during initialization when a
Messenger plugin has none yet, mirroring the creation already done for
plugins that support Messenger from the start.
Fixes#653
Co-Authored-By: Claude <noreply@anthropic.com>
In debug mode this outputs the oidc discovery
2026-07-07T20:51:14+02:00 DBG discover config={"authorization_endpoint":"http://192.168.178.2:5556/dex/auth","claims_supported":["iss","sub","aud","iat","exp","email","email_verified","locale","name","preferred_username","at_hash"],"code_challenge_methods_supported":["S256","plain"],"device_authorization_endpoint":"http://192.168.178.2:5556/dex/device/code","grant_types_supported":["authorization_code","refresh_token","urn:ietf:params:oauth:grant-type:device_code","urn:ietf:params:oauth:grant-type:token-exchange"],"id_token_signing_alg_values_supported":["RS256"],"introspection_endpoint":"http://192.168.178.2:5556/dex/token/introspect","issuer":"http://192.168.178.2:5556/dex","jwks_uri":"http://192.168.178.2:5556/dex/keys","request_uri_parameter_supported":false,"response_types_supported":["code"],"scopes_supported":["openid","email","groups","profile","offline_access"],"subject_types_supported":["public"],"token_endpoint":"http://192.168.178.2:5556/dex/token","token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_post"],"userinfo_endpoint":"http://192.168.178.2:5556/dex/userinfo"} rp.function=NewRelyingPartyOIDC
