AkkomaGang/akkoma
AkkomaGang/akkoma
17
70
Fork 118
Code Issues 149 Pull requests 15 Projects 2 Releases 24 Packages Wiki Activity

search/db: checkout connection #1131

Merged
Oneric merged 5 commits from Oneric/akkoma:post-search-db-conn-checkout into develop 2026-05-29 17:50:22 +00:00
Conversation 1 Commits 5 Files changed 7 +170 -57
Oneric commented 2026-05-25 16:36:08 +00:00
Owner
Copy link

Besides the actual search query we also run a few prep queries. Let’s avoid having to wait for a new db conn each time.

Not sure how much difference this actually makes, but with network bits already excluded it shouldn’t hurt at least.
For user search this doesn’t seem worthwhile (except with resolve=false) as everything before the final step may perform network fetches and the final step itself has no (obvious) extra prep queries baked in, just the main query itself.

Besides the actual search query we also run a few prep queries. Let’s avoid having to wait for a new db conn each time. --- Not sure how much difference this actually makes, but with network bits already excluded it shouldn’t hurt at least. For user search this doesn’t seem worthwhile (except with `resolve=false`) as everything before the final step may perform network fetches and the final step itself has no (obvious) extra prep queries baked in, just the main query itself.
Each task might perform some additional, typically small
prep queries as well as elixir-side processing, so lets
add a bit of extra time instead of using the max time of
just the mai query itself.
search/db: checkout connection
Some checks failed
ci/woodpecker/pr/test/2 Pipeline failed
Details
ci/woodpecker/pr/test/1 Pipeline failed
Details
8cdd885223 
Besides the actual search query we also run a
few prep queries. Let’s avoid having to wait
for a new db conn each time
Oneric force-pushed post-search-db-conn-checkout from 8cdd885223
Some checks failed
ci/woodpecker/pr/test/2 Pipeline failed
Details
ci/woodpecker/pr/test/1 Pipeline failed
Details
to 7b5a7f8519
All checks were successful
ci/woodpecker/pr/test/2 Pipeline was successful
Details
ci/woodpecker/pr/test/1 Pipeline was successful
Details
2026-05-25 16:44:13 +00:00 Compare
cosmetic/search/db: drop unused function
All checks were successful
ci/woodpecker/pr/test/2 Pipeline was successful
Details
ci/woodpecker/pr/test/1 Pipeline was successful
Details
1fc689162c 
Leftover from a restructure during local development
floatingghost reviewed 2026-05-25 18:19:35 +00:00
lib/pleroma/web/mastodon_api/controllers/search_controller.ex Outdated
@ -68,3 +68,3 @@
query = String.trim(query)
options = search_options(params, user)
timeout = Keyword.get(Repo.config(), :timeout, 15_000)
timeout = 2 * Keyword.get(Repo.config(), :timeout, 15_000)
floatingghost commented 2026-05-25 18:19:35 +00:00
Owner
Copy link

maybe worth just doubling the default timeout to 30s instead of the configured amount - would seem weird to derive the value from the config instead of taking it verbatim

maybe worth just doubling the default timeout to 30s instead of the configured amount - would seem weird to derive the value from the config instead of taking it verbatim
Oneric commented 2026-05-25 18:42:58 +00:00
Author
Owner
Copy link

the value we read here from the config is the timeout for a single db query.

However, here the local timeout value is used as the deadline for each search task and the user and post search tasks will both execute multiple db queries + some elixir-side processing and possibly even network requests; so the verbatim timeout for a single db query from config imho doesn’t make too much sense here. Nor does raising the default for single queries to better suit a non-db-query use case.

Adding a multiplier admittedly also kinda adhoc. A separate timeout config might be ideal in some sense, but then it’s possible to end up with somewhat nonsensical values where the task timeout is shorter than the repo timeout for a single query. But perhaps that’s worth the increased specifity?

the value we read here from the config is the timeout for a single db query. However, here the local `timeout` value is used as the deadline for each search _task_ and the user and post search tasks will both execute _multiple_ db queries + some elixir-side processing and possibly even network requests; so the verbatim timeout for a single db query from config imho doesn’t make too much sense here. Nor does raising the default for single queries to better suit a non-db-query use case. Adding a multiplier admittedly also kinda adhoc. A separate timeout config might be ideal in some sense, but then it’s possible to end up with somewhat nonsensical values where the task timeout is shorter than the repo timeout for a single query. But perhaps that’s worth the increased specifity?
Oneric commented 2026-05-26 11:49:47 +00:00
Author
Owner
Copy link

Added a new config option specifically for these tasks

And also added a checkout to user search if no network requests are being made at all and updated search docs to be in one place, more comprehensive and properly formatted

Added a new config option specifically for these tasks And also added a checkout to user search if no network requests are being made at all and updated search docs to be in one place, more comprehensive and properly formatted
Oneric marked this conversation as resolved
Oneric force-pushed post-search-db-conn-checkout from 1fc689162c
All checks were successful
ci/woodpecker/pr/test/2 Pipeline was successful
Details
ci/woodpecker/pr/test/1 Pipeline was successful
Details
to f8096e309d
Some checks failed
ci/woodpecker/pr/test/2 Pipeline was successful
Details
ci/woodpecker/pr/test/1 Pipeline failed
Details
2026-05-26 11:36:00 +00:00 Compare
Oneric force-pushed post-search-db-conn-checkout from f8096e309d
Some checks failed
ci/woodpecker/pr/test/2 Pipeline was successful
Details
ci/woodpecker/pr/test/1 Pipeline failed
Details
to 1630dd38a4
All checks were successful
ci/woodpecker/pr/test/2 Pipeline was successful
Details
ci/woodpecker/pr/test/1 Pipeline was successful
Details
2026-05-26 11:52:22 +00:00 Compare
Oneric force-pushed post-search-db-conn-checkout from 1630dd38a4
All checks were successful
ci/woodpecker/pr/test/2 Pipeline was successful
Details
ci/woodpecker/pr/test/1 Pipeline was successful
Details
to 435d56248a
All checks were successful
ci/woodpecker/pr/test/2 Pipeline was successful
Details
ci/woodpecker/pr/test/1 Pipeline was successful
Details
2026-05-26 13:30:54 +00:00 Compare
Oneric force-pushed post-search-db-conn-checkout from 435d56248a
All checks were successful
ci/woodpecker/pr/test/2 Pipeline was successful
Details
ci/woodpecker/pr/test/1 Pipeline was successful
Details
to 1f214f94f9
All checks were successful
ci/woodpecker/pr/test/2 Pipeline was successful
Details
ci/woodpecker/pr/test/1 Pipeline was successful
Details
2026-05-28 00:04:08 +00:00 Compare
Oneric merged commit ceac69fec0 into develop 2026-05-29 17:50:22 +00:00
Oneric deleted branch post-search-db-conn-checkout 2026-05-29 17:50:22 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
approved, awaiting change

   
broken setup

Issue arose from a misconfiguration by the admin, custom patches, manual db edits or similar

  
bug

Something is not working

  
cannot reproduce

   
configuration

This requires config changes

  
documentation

This is about human-readable docs

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
extremely low priority

   
feature request

Something new?

  
Fix it yourself

Support has been attempted

  
help wanted

Need some help

  
invalid

Something is wrong

  
mastodon_api

   
needs change/feedback

Issue or PR is stalled on response from the author or a third party

  
needs docs

   
needs tests

   
not a bug

   
not our bug

Bug in a dependency of ours (meaning we can't just fix it), or in another AP implementation or client interfacing with Akkoma (which needs to be fixed on their end)

  
planned

   
pleroma_api

   
privacy

   
question

More information is needed

  
static_fe

   
triage

   
wontfix

This won't be fixed

No labels
approved, awaiting change
broken setup
bug
cannot reproduce
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs change/feedback
needs docs
needs tests
not a bug
not our bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
AkkomaGang/akkoma!1131
No description provided.