mirror of
https://github.com/simplex-chat/simplex-chat.git
synced 2026-08-14 09:20:28 +00:00
wip
This commit is contained in:
@@ -34,7 +34,7 @@ data DirectorySearchResponse = DirectorySearchResponse
|
||||
|
||||
This is the bot's existing text search (`STSearch`), a `LIKE '%…%'` over registered group and channel **profiles** — display name, full name, short description, welcome message, and the SimpleX name when the domain is verified (Store.hs:394-401). No conversation content is involved. No sort parameter: the directory's other modes are the separate `/all` and `/new` commands (Service.hs:1141-1142). No page-size parameter: it uses its own `searchResults` (Service.hs:1284, default 10).
|
||||
|
||||
Paging is `/next` with the state moved. In chat the cursor lives in a per-contact map (`searchRequests`, Service.hs:101, written :1288-1299, 5-minute expiry :1131); an RPC caller has no contact, so it travels in the request and nothing expires. `DirectoryCursor` is opaque — the app only echoes it, so the paging fix below needs no app change.
|
||||
Paging is `/next` with the state moved. In chat the directory keys the saved search on the contact (`TM.lookup (contactId' ct) searchRequests`, Service.hs:1128, written :1299, 5-minute expiry :1131). Over RPC it gets only a per-request `invId` (Subscriber.hs:1368) — nothing identifying the requester — so there is no key to look a `next` up against, and the cursor comes back in the request instead. `DirectoryCursor` is opaque: it is the `lastGroup` the directory already stores, held by the client, so the paging fix below needs no app change.
|
||||
|
||||
Entry differences from `DirectoryEntry`: `welcomeMessage` dropped (it carries the whole group description, Listing.hs:105-119); `shortDescr` sent as stored `Text` (Types.hs:882) rather than `MarkdownList`, which would ship a Linux-shaped `Format` iOS cannot decode — apps parse markdown locally via `chat_parse_markdown` (Core.kt:31) if the row needs it; `imageFile` (a web-listing path) replaced by `image`, the profile picture the bot already sends as `MCImage` (Service.hs:1310), bounded to 12,500 bytes (GroupProfileView.kt:95). Against the ~14.7KB envelope that is about one entry per response today — the handler fills `entries` until the envelope is full and returns a cursor for the rest, so streaming later changes the transport, not the client model.
|
||||
|
||||
@@ -42,7 +42,7 @@ Entry differences from `DirectoryEntry`: `welcomeMessage` dropped (it carries th
|
||||
|
||||
Run the handler off the event loop (`forkIO`, as `sendFoundGroups` does at Service.hs:1301) with bounded concurrency: the directory processes registrations, captchas and owner commands on one sequential consumer (Service.hs:263-269). Cap the request rate globally — a service request carries no caller identity to key a per-caller limit on — and size the cap knowing each request also leaves agent state on the responder (`APISendServiceResponse` returns an `AgentConnId`, Commands.hs:1472).
|
||||
|
||||
**Cursor fix — separate commit, first.** The search orders by `members_count DESC, group_reg_id ASC` (Store.hs:388) but pages with `AND r.group_id > ?` (:378), a column unrelated to the sort key, so pages skip and repeat rows; `testSearchGroups` (DirectoryTests.hs:505) misses it because its fixture aligns counts with ids. Make the cursor the sort key, tie-breaking on `r.group_id` (unique, Migrations.hs:36; `group_reg_id` is not in `groupRegFields`, Store.hs:450), and use the OR form since the mixed-direction sort rules out a row-value comparison:
|
||||
**Cursor fix — separate commit, first.** The search orders by `members_count DESC, group_reg_id ASC` (Store.hs:388) but pages with `AND r.group_id > ?` (:378), a column unrelated to the sort key, so pages skip and repeat rows; `testSearchGroups` (DirectoryTests.hs:505) misses it because its fixture aligns counts with ids. "Continue after the last row" here means "fewer members than it had", so the cursor has to carry the member count; the id only breaks ties between equal counts. Tie-break on `r.group_id` (unique, Migrations.hs:36; `group_reg_id` is not in `groupRegFields`, Store.hs:450), and use the OR form, since the mixed-direction sort rules out a row-value comparison:
|
||||
|
||||
```sql
|
||||
AND (g.summary_current_members_count < ? OR (g.summary_current_members_count = ? AND r.group_id > ?))
|
||||
|
||||
Reference in New Issue
Block a user