Commandar Rick - Hey @shibo , I tried working o...
Hey @shibo , I tried working on issue #1933 and was able to reproduce it on production tscircuit.com by manually invalidating the session token. The bug reproduced perfectly - the UI still showed me as logged in (profile picture visible) but all API calls failed with 401 errors and multiple toast notifications about being unauthenticated.
15 Replies
However, when I tried to reproduce it locally, it didn't work because the local fake API uses a simple test token ("1234") instead of proper JWT tokens. The fake API's auth middleware has a fallback that accepts any session in development mode, so it doesn't properly validate or reject invalidated sessions like the production API does. I believe the root cause of the multiple toast issue is that the axios wrapper in use-axios.tsx shows a toast on every 401 error, and since multiple API calls happen simultaneously (packages list, user data, etc.), each one triggers its own toast. The real issue is that there's no session validation on app mount - the frontend trusts whatever is in localStorage without checking if it's still valid on the backend. Since I can't properly reproduce and verify the fix locally due to the fake API limitations, I'm working around it by testing directly against production, but it makes the development cycle a bit challenging.
I can run the local frontend against the production API by using VITE_SNIPPETS_API_URL=https://api.tscircuit.com bun run dev. This way I get real JWT tokens and proper session validation, so I can reproduce and test the bug locally while still being able to iterate on frontend fixes quickly. Does that sound good?
huh so sm weird happened that didnt let me login using github like expected but it did throw a bunch of unauthenticated error
might be enough to reproduce and fix atleast the toast error
so i think i fixed the too many toasts issue
lemme send a before and after video
This was before
The issue happens when a user's session expires on the backend but remains in localStorage, causing the UI to show them as logged in while all API calls fail with 401 errors. This creates multiple toast notifications since each failed request triggers its own "Unauthorized" toast.
I fixed this in src/hooks/use-axios.tsx by adding two key changes: First, a has401ToastBeenShown (could use a better var name) flag that prevents duplicate toasts when multiple API calls fail simultaneously - it only shows one toast and resets after 6 seconds. Second, when a 401 is detected, the code now automatically calls setSession(null) to clear the stale session from localStorage, immediately updating the UI to show the logged-out state and eliminating the confusing mismatch between what the user sees and their actual auth status.
While I couldn't fully test the token invalidation locally due to the fake API using simple test tokens instead of JWTs, the fix still solves the core issue. The automatic session clearing ensures that whenever the backend rejects a request with 401, the frontend syncs its state by removing the invalid session, preventing the "ghost authentication" state and providing a cleaner user experience with just one toast instead of multiple spam notifications.
This solves both parts of the issue:
Toast spam - The flag prevents multiple toasts from showing
Ghost authentication state - The setSession(null) automatically clears the stale session from localStorage, so the UI immediately updates to show you're logged out (profile picture disappears, authenticated elements hidden)
So it fixes both the symptom (multiple toasts) and the root cause (stale session in localStorage making you appear logged in when you're not)
if i can validate against a proper session token that would be golden but i havent figured that part out, so i think so far only the toast thing could be considered somewhat validated
localStorage.setItem('session_store', JSON.stringify({
state: {
session: {
token: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzZXNzaW9uX2lkIjoiNTIxMDE4YmMtNGI5YS00OWI1LWFkZWYtMGJjMTIwZTg5N2JmIiwiYWNjb3VudF9pZCI6IjI2NDBhZWFlLWI2NDAtNDA4ZC1iMDQzLWM3NzBmMTI3M2E2YSIsImdpdGh1Yl91c2VybmFtZSI6IlJhZ2hhdkFyb3JhMTQiLCJlbWFpbCI6InJraW5nZXIyMDA0QGdtYWlsLmNvbSIsImlhdCI6MTc2MjI5MjI2OSwiZXhwIjoyMzY3MDkyMjY5fQ.lYhWP9wzSavFCPUAVLDHeyu_fXesQIqxuhD7_Dy_Wcg",
account_id: "2640aeae-b640-408d-b043-c770f1273a6a",
session_id: "521018bc-4b9a-49b5-adef-0bc120e897bf",
github_username: "RaghavArora14"
},
should_onboarding_tips_be_closed: false
},
version: 0
}))
location.reload()
tried to login using this token so i can later invalidate this and test the working of the fix, this works hope this is okay, if theres any better way to lemme know
Repro by manually setting the session token as same as my github token on tscircuit.com
after the fix:
(created a fresh session token after loging in again on tscircuit.com and use that to test this)
ik this might not be perfect but this seems like the right direction
check this out whenever you get a chance, ty
@shibo
will take a look soon
Okay just lemme know 👍, starting on another issue meanwhile
can you please link the issue
isn't this a backend issue? if it is then you can't work on it
are you trying to fix an issue that only exists in the backend and not the fake api?
I've implemented the session validation in the fake API to mirror what should exist in the real backend. The changes ensure that when a JWT token is presented, we verify the session still exists in the database before accepting it. This prevents deleted/logged-out sessions from being used. The frontend code (authorize.tsx, dev-login.tsx) already works with both APIs. If the real backend doesn't currently validate sessions this way, then yes - this would need to be implemented there too. I can't work on the actual backend, but I've demonstrated the fix in the fake API so local development behaves correctly. Does the real backend already have this session validation logic
I've only modified the fake API in this frontend repo. The real backend would need the same session validation added to its auth middleware. Should I create an issue in the backend repo documenting what needs to be implemented, or does someone on the handeling the backend repo want to review the fake API changes first to see the approach?
ok, please make a PR and let me see it
yes working on the circuit-to-svg issue rn will do shortly, till when are you up?
https://github.com/tscircuit/tscircuit.com/pull/1955
sorry for the delay
@shibo please check this and this whener you get time
https://github.com/tscircuit/circuit-to-svg/pull/416