seoul.systems
commits
Refactor link query APIs to use an explicit Order enum
(OldestToNewest, NewestToOldest) instead of a boolean
reverse flag for better clarity and maintainability.
As outlined in the description of issue #4 we increase:
- the default response limit from 16 to __100__
- the maximum from 100 to __1000_
Adds a new --collect-metrics (presence) flag to make metrics collection
opt-in. The new default is to __not__ collect any metrics, i.e. neither
spawning the monitoring thread nor starting the metrics server server
that exposes these.
The initial implementation of the reverse ordering feature had a flaw
in how it handled pagination. When `reverse=true` was set, the code
would reverse the entire collection before applying pagination
slicing, which broke the cursor logic. Cursor positions were
calculated relative to the original ordering but applied to a reversed
set of items, causing duplicate results or skipped items across page
boundaries.
The fix restructures pagination to account for reverse ordering:
- In reverse mode, pagination starts from the beginning (oldest items)
and moves forward, with begin/end indices calculated accordingly
- In normal mode, pagination continues working backward from the end
(newest items) as before
- The result slice is reversed __only after__ pagination boundaries
are established, ensuring cursor values remain consistent
Applied to both storage backends (mem_store and rocks_store) for
consistent behavior across implementations.
Adds test coverage for the reverse parameter in get_links and
get_many_to_many_counts methods. Tests verify that reverse: true
returns results in oldest-first/descending order while reverse:
false returns newest-first/ascending order.
Before all our testing was done manually. This fixes the remaining failing automatic tests.
- Add "reverse" boolean parameter to three endpoints:
1. getManyToManyCounts (grouped counts)
2. getBacklinks (links to subject)
3. links (target links)
- Implement reverse iteration logic in both storage backends (mem_store
and rocks_store) for __reverse-chronological__ ordering
- Update HTML templates with (reverse) checkboxes
Add lexicon documents for the XRPC endpoints
pin fjall git dep to specific rev
when tungstenite said we should keep polling until ConnectionClosed, they probably didn't mean ignore all other errors.
Capitalized my favorite error messages
many-to-many counts
(also since the vercel app was broken by bots, but mostly because fuck vercel.)
Filter links by linker dids
atproto queries do arrays like this
mutex-wrapping the storage accidentally serializes all access which oops but also whatever
and without relying on indirect tokio scheduling for timing measurements
atrium fork for the https handle method fix
The initial implementation of the reverse ordering feature had a flaw
in how it handled pagination. When `reverse=true` was set, the code
would reverse the entire collection before applying pagination
slicing, which broke the cursor logic. Cursor positions were
calculated relative to the original ordering but applied to a reversed
set of items, causing duplicate results or skipped items across page
boundaries.
The fix restructures pagination to account for reverse ordering:
- In reverse mode, pagination starts from the beginning (oldest items)
and moves forward, with begin/end indices calculated accordingly
- In normal mode, pagination continues working backward from the end
(newest items) as before
- The result slice is reversed __only after__ pagination boundaries
are established, ensuring cursor values remain consistent
Applied to both storage backends (mem_store and rocks_store) for
consistent behavior across implementations.
- Add "reverse" boolean parameter to three endpoints:
1. getManyToManyCounts (grouped counts)
2. getBacklinks (links to subject)
3. links (target links)
- Implement reverse iteration logic in both storage backends (mem_store
and rocks_store) for __reverse-chronological__ ordering
- Update HTML templates with (reverse) checkboxes
basic api stuff