feature: Fetch billing historicals and display them on the billing page #731
Conversation
jshearer
force-pushed
the
feature/billing_historicals
branch
from
5ad7997 to
011f22a
Compare
src/api/billing.ts
Outdated
| // the promise-like object returned by the Supabase SDK, we lose that | ||
| // hidden URL field in the process, breaking SWR. | ||
| // So... for the moment, this hacks it back into existence. | ||
| (prom as any).url = url; |
There was a problem hiding this comment.
Are we trying to make sure we get this in for the end of the month? If so - we can review this solution. If not... I'd say we should take a slightly different route. The fetchers have more than just the url. I do not think this would cause any major issues but is a worry to me.
There was a problem hiding this comment.
Yeah we are unfortunately. If you give me a hint I'm sure I can figure out the non-hacky solution tomorrow!
There was a problem hiding this comment.
Sweet - this looks a lot safer to me.
So my initial thought on this one was we should really just fetch the two "types" of rows as two different calls. So we'd make a call to fetch the current month and another to fetch the older ones.
That way we can display right away and easily handle the differences without too many if/else blocks.
However, that could take a lot of effort and time for minimal benefit.
Moving some basic code
There was a problem hiding this comment.
LGTM - pushed two small changes myself (a comment and moving the select into a const)
Local Test
My local is old so the table isn't there and everything still works (but does not show up obviously) so feel good in terms of risk
Production Test
After pointing to prod I tested with the two tenants I have access to. Everything looks good and seems to be working just fine.
Only concern is that the screenshot shows a tons of decimal places but we can worry about that later on.
Changes
Transparently pull data from the new
billing_historicalstable when fetching billing data for previous months. One interesting side-effect is that the data for the graphs ofData Volume by MonthandTask Hours by Monthwill also be frozen and fetched frombilling_historicals. I... think this is fine, just observing that it'll become possible to manually edit those values for prior months. We probably shouldn't do that though?We also decided to not implement the ability to view line-items in the UI yet, as it's entirely possible/likely that until we finish cleaning up this data, line-items from prior months may still be wrong, even if the total cost is correct.
Screenshots
August is "live" data, June and July are
billing_historicalsNote:
Do not merge before estuary/flow#1163 is live.