[bug] PUT /api/v1/akkoma/preferred_frontend might be broken #677
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#677
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Your setup
From source
Extra details
Alpine 3.19
Version
6fb91d79f3
(at the time of writing: current develop)PostgreSQL version
16
What were you trying to do?
Whatever I try, I’m unable to get anything but an error (due to non-matching function clause) when trying to use the
PUT /api/v1/akkoma/prefered_frontened
API endpoint. It seems like at the point it gets to callingavailable_frontends(conn, _params)
the connection’s body parameters are always empty resulting in there never being a match.The related
GET /api/v1/akkoma/prefered_frontened/available
works as expected and with only a minor modification to the request body and adding an authorisation header thePUT /api/v1/akkoma/frontend_settings/pleroma-fe/custom
endpoint works as well.I tried many variations of curl invocations and JS fetch API but none let me use the preferred_frontend API.
While somewhat embarrassing, ideally i’m just missing the obvious and everything is actually fine and I’d appreciate if someone could teach this sillyhead how to properly use this.
However, given the other PUT API works with basically the same request and the frontend endpoint was only reachable via
/api/v1/akkoma/api/v1/akkoma/preferred_frontend
until recently, it might also just be actually broken.The Phoenix error page shown on unsuccessful requests indicates the empty body parameters, but at the same time reports the
frontend_name = "pleroma-fe/stable"
being passed in as a parameter at the bottom. As a wild guess, does maybe something strip out body parameters from unauthenticated (PUT) requests before it gets to theavailable_frontends(conn, _params)
function?Note this does not affect the related browser config site under
/akkoma/frontend
which can successfully set the cookie.What did you expect to happen?
No response
What actually happened?
Working request for settings:
Output:
Failing preferred_frontend request:
Yielding this HTML error page (at least in dev env): tmp__bug_frontend.html
Logs
No response
Severity
I can manage
Have you searched for this issue?
[bug] PUT /api/v1/akkoma/prefered_frontened might be brokento [bug] PUT /api/v1/akkoma/preferred_frontend might be brokenThis was a bit difficult to track down, but the reason was OpenAPI spec, which had operation id duplicated from another endpoint and indeed was scrubbing unknown parameters from the request.
Fixed by #680, thanks katafrakt!