[Better Auth] auth.api.getAccessToken returns Uncaught APIError: Account not found
I have tried the following
using google oauth
I have also tried using the betterauthcomponent and get the header and pass it along it returns
Uncaught APIError: Failed to get a valid access token
@erquhart40 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
hmm
researching
Try with headers, without the userID
You will absolutely need headers for any server side call to better auth
I see you said "tried using the betterauthcomponent" - any Better Auth implementation not using the component would be out of scope for me, just fyi
But if you're using the component and passing headers without the userId, it should work
Uncaught APIError: Failed to get a valid access token
Can you log the headers before the request and make sure there's a better auth cookie in there
'{\n "_headersList": [\n [\n "authorization",\n "Bearer iFdF36qGyltxAdofayx833PRlRh8SUwl"\n ]\n ]\n}'
That's a session token - can you look at the better auth session table in your convex dashboard and see if any have a token field matching that
hmm sounds like it's Google that's having a problem specifically
hmm
(maybe)
you're on the latest @convex-dev/better-auth right
yep
0.7.0 just dropped, update and see if that fixes
when
i jus did a fresh install of node modules today
lol
just dropped
am not able to login in at all with .7
it works fine if i revert it to 6..
nvm, lemme debug a lil more n update
Did you do the migration steps
i jus cleared all tables am still on dev
rn am not able to push for sm reason, i even reverted back to a prev commit
Yeah not sure what to say on that. the only .log calls we have is console.log. Guessing console is defined.
idk, i commented out the convex .env.local created a new cloud instance, copy pasted my envs and it works
istg
i even tried reverting back, restarting my pc, network, nothing worked
log:
this works, current config
Works as in google auth is working too
ok i might have to escalate the issue
the deployment seems to be failing when I abort an action using abortcontroller after a console.log
should i use the support or jus ping jamie/wayne here?
@Barrel Of Lube feel free to create a support ticket. that's the way to ensure things 100% get solved
it works if u give it some time to recover
is it normal to get 200ms latency for auth verification wth better auth?
HTTP auth endpoint have around 200ms latency wth better auth

my prev prod wth convex auth

@erquhart ^
Yeah, it’s high right now because the better auth db calls are all separate Convex functions. Running the whole thing in a single query/mutation is on the roadmap for next release to take this down.
@Barrel Of Lube circling back here - realizing that running entire Better Auth endpoint calls in a single transaction, which was the plan for reducing the time of these functions, has two problems:
1. There's no way to get your Better Auth config into a mutation in the component. I was hoping we could work around this, but it's a fundamental part of component isolation - nothing can get into those functions unless they're present at bundle time, similar to your app's Convex functions.
2. The cached responses from sub queries are already absorbing some of the inefficiency, and queries represent the bulk of the internal requests. Which means it's less clear whether this will meaningfully improve times. It may, just hard to say how much.
That said, the numbers in your screenshot are in the same range as what you would see from Convex Auth, which isn't doing subqueries and isn't running all of Better Auth (which I suspected may have been another major culprit here, seems like it's not).
Oh you posted comparison numbers! Your numbers are pretty different from what I've seen in other implementations, hmm

Those are really fast, this is interesting. I'm going to try a fresh install.
one of my most painful setbacks, had to cut down so many features

:sad-cowboy:
yeah
still messing with numbers to figure out what's actually happening
@erquhart can we do something like
- serve /.well-known/openid-configuration and JWKS directly as lightweight HTTP routes (no auth.handler, no redirect), with cache headers
- remove the redirect for discovery
- externalize keys (env/secret) so JWKS can be returned statically and match what signs tokens
It looks like http action perf is affected by component usage currently, so getting the key won’t be sped up by storing it statically. That still needs to be looked into. We can do customJwt to get rid of the oidc discovery call, though.
also can you check the latency for convexAdapter, if its not much < 50ms on avg, then i supoose we can make the better auth instance singleton as well
The adapter primarily runs Convex functions in the component space, so it's execution time is impacted by a number of things. The Better Auth instance is a singleton when accessed through http action calls, which applies to the numbers you're focused on, let me know if I'm missing your point there.
Yep I found the instance
I don’t see any other way to solve it rn, first 2 suggestions are somewhat of an alternative medicine typaa fix
Getting rid of the oidc discovery call will have concrete impact at least. I'll look at that soon.