Skip to content

fix(open-interest): return OI history in ascending order for charts #171

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
6figpsolseeker wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix(open-interest): return OI history in ascending order for charts #171

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions src/routes/open-interest.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,12 +77,15 @@ export function openInterestRoutes(): Hono {
}, 404);
}

// Fetch historical OI data
// Fetch historical OI data in ascending order (oldest→newest) so chart
// components can feed the series directly into lightweight-charts setData(),
// which requires strictly ascending timestamps. Previously returned DESC
// (newest first) — same issue that was fixed in prices.ts (see GH#xxx).
const { data: history, error: historyError } = await getSupabase()
.from("oi_history")
.select("timestamp, total_oi, net_lp_pos")
.eq("market_slab", slab)
.order("timestamp", { ascending: false })
.order("timestamp", { ascending: true })
.limit(100);
Comment on lines +88 to 89
Copy link
Copy Markdown

@coderabbitai coderabbitai bot Apr 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

In PostgREST/Supabase, does order("timestamp", { ascending: true }).limit(100) return the oldest 100 rows? What is the recommended pattern to return the latest 100 rows in ascending timestamp order?

💡 Result:

Yes. In PostgREST (and therefore Supabase), order('timestamp', { ascending: true }).limit(100) is equivalent to ORDER BY timestamp ASC LIMIT 100, so it returns the oldest 100 rows by timestamp (smallest/earliest timestamps first). (postgrest.org)

Recommended pattern to get “latest 100, but displayed oldest→newest”

Because you can’t apply two different sort orders (DESC to pick the last 100, then ASC to present them) in a single flat PostgREST query, the common patterns are:

A) Fetch latest 100 in descending order, then reverse client-side

const { data } = await supabase
  .from('events')
  .select('*')
  .order('timestamp', { ascending: false })
  .order('id', { ascending: false })   // tie-breaker for identical timestamps
  .limit(100)

const latest100Ascending = (data ?? []).slice().reverse()

PostgREST supports ordering by multiple columns (comma-separated), and Supabase’s .order() can be called multiple times—use a unique tie-breaker like id for deterministic results when timestamps collide. (postgrest.org)

B) Do it server-side via a view (or an rpc function)

create view latest_events_100 as
select *
from (
  select *
  from events
  order by "timestamp" desc, id desc
  limit 100
) t
order by "timestamp" asc, id asc;

Then query latest_events_100 normally (already in ascending order). This “subquery then reorder” approach is generally required when you need “last N rows, but returned ascending.” (stackoverflow.com)

Citations:

ascending: true with limit(100) returns the oldest 100 records, not the latest.

This changes the data window semantics. If the table has >100 rows, the query serves the oldest records instead of the most recent data. Fetch with ascending: false and then reverse client-side to get the latest 100 in ascending order for the chart.

Proposed fix 
-        .order("timestamp", { ascending: true })
+        .order("timestamp", { ascending: false })
         .limit(100);

@@
       const filteredHistory = (history ?? [])
         .filter((h) => !isPhantomOiRecord(h))
+        .reverse()
         .map((h) => ({
           timestamp: h.timestamp,
           totalOi: h.total_oi,
           netLpPos: h.net_lp_pos,
         }));
🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@src/routes/open-interest.ts` around lines 88 - 89, The query currently uses
.order("timestamp", { ascending: true }).limit(100) which returns the oldest 100
rows; change the order to .order("timestamp", { ascending: false }).limit(100)
to fetch the latest 100 rows, then reverse the returned array client-side before
passing it to the chart so the data is in ascending timestamp order; update the
code around the query call (the chain containing .order("timestamp", {
ascending: ... }).limit(100)) and ensure any variable that holds the fetched
rows is reversed (e.g., rows.reverse()) before rendering.


if (historyError) {
Expand Down