Warning : Multiple GoTrueClient instances detected in the same browser context
Hello,
I use Supabase in nextjs with next-auth and got the"Multiple GoTrueClient instances..." warning in the console when i want to pass the next-auth bearer token to the supabase client. I have tried multiple ways to implement createClient including context at the root, i checked on github repos, but i'm still stuck...
1 - Singleton Approach. No warning but can't pass the bearer token
"
const client = createClient(process.env.SUPABASE_URL, process.env.SUPABASE_KEY);
const supabase = () => client;
export default supabase;
"
2 - Classic approach. It works but many warnings in the console
"
export const supabaseClient = async (supabaseAccessToken) => {
const supabase = createClient(
process.env.NEXT_PUBLIC_SUPABASE_URL,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY,
{
global: {
headers: { Authorization:
Bearer ${supabaseAccessToken} },
},
}
);
return supabase;
};
"
Ideally i would like to fetch the token from useSession directly in my supabase client file so that i don't have to pass it as params.
If there is no solution, will this affect performances ? How can i hide this warning ?
Thanks for your help26 Replies
As long as you are on a server set persistSession:false in createClient
I mainly use createClient for client side fetching. I have already tried persistSession:false but i didn't notice any improvement, maybe because as i use next-auth as auth/session.
So exactly what is the full error message. I may have assumed it is the one with the persistSession warning.
Otherwise on a browser you normally share the same client. You can set the localStorage key to be different so they don't interact but I would not think you would do that unless you are trying to have multiple users signed in at once.
This is the warning message : "Multiple GoTrueClient instances detected in the same browser context. It is not an error, but this should be avoided as it may produce undefined behavior when used concurrently under the same storage key"
OK that is the one, but I thought it used to mention persistSession.
Anyway it is just warning you have have multiple clients sharing localStorage so the sessions will interact.
Normally on a browser you have one client for everything for a single user session.
Yeah, I was getting ready to ask what your use-case is for needing to manually set the header.
I just pass the bearer token that i get from next-auth session, as it's recommended in the supabase/next-auth tutorial
no specific use-case, just authorizing a user to fetch his data
If you don't need to use supabase auth, then set persistSession:false and autoRefreshToken:false.
https://supabase.com/docs/reference/javascript/initializing?example=with-additional-parameters
thanks, i've added both persistSession:false and autoRefreshToken:false but it's still there :/. I will investigate a bit more later
I believe it comes down to you have 2 clients on the same browser using the same local storage key. Normally this issue is server related. On a browser it is not an error to have 2 clients sharing the key (and in your case I don't think you care as you are not using the session).
Also you should show your createClient with init because I'm pretty sure persistSession:false eliminates any local storage use.
Also you should show your createClient with init because I'm pretty sure persistSession:false eliminates any local storage use.
I don't see any key in localstorage. This is the client file : import { createClient } from "@supabase/supabase-js";
export const supabaseClient = async (supabaseAccessToken) => {
const supabase = createClient(
process.env.NEXT_PUBLIC_SUPABASE_URL,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY,
{
global: {
headers: { Authorization:
Bearer ${supabaseAccessToken} },
},
}
);
return supabase;
};I know you were checking out for the night, but where is the persistSession:false setting?
i've actually tried various ways. here is another one import { createClient } from "@supabase/supabase-js";
import { useSession } from "next-auth/react";
const useSupabase = (schema) => {
if (!schema) schema = "public";
const session = useSession();
const accessToken = session?.data?.supabaseAccessToken;
const supabaseClient = createClient(
process.env.NEXT_PUBLIC_SUPABASE_URL,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY,
{
auth: {
persistSession: false,
autoRefreshToken: false,
},
global: {
headers: {
Authorization:
Bearer ${accessToken},
},
},
db: {
schema: schema,
},
}
);
return supabaseClient;
};
export default useSupabase;The 2nd one looks correct. If all are called with that I would not expect the warning. But remember the warning really does not impact you as you are setting the authorization header directly and don't care about sessions and local storage.
ah cool ! thanks
is it possible to hide it ?
LOL... sorry. I thought persistSession:false would hide it. That is the recommended solution for months. So I'm puzzled.
The warning is supposed to be from a 2nd client noticing a first one using the same local storage.
yes that"s why i sent a message here, i was desperate after trying so many times. I will try again tomorrow with a different laptop and setup. This is strange i don't see anything related to supabase in local storage
There won't be because you are not using supabase auth.
okay
Thank you for your help anyway 🙂
It may be the message is looser recently and just warns anytime you have two clients in the same space. I'll try and look tomorrow, but will be out quite a bit. I'm noticing the same warning in my test instance which has two separate local storage keys for testing multiple users in same browser. So something could have changed.
But it is just a warning ... so not an emergency as it won't impact you.
Good to know but will try to get rid of it as it takes much space in the console. Also, i tried to switch off the react strict mode but nothing changed
If they changed it then all bets are off if it can be turned off.
:/
So seems on a browser it does not care about anything like persistSession.
So seems solution is not to have multiple clients on same browser if you can. But deal with the warning if you can't.
If you want, open a github issue and explain your situation. Maybe they'll implement a bypass.
For example, the ssr auth helper package allows you to pass an
isSingleton boolean. It defaults to true and caches your initial browser client and always returns that, instead of creating a new client. Passing false bypasses the caching feature and creates multiple clients. So, if gotrue-js would add a similar boolean, it would check that boolean and bypass the warning if false.