Closed 4leite closed 5 months ago
The build should pass because the secret will be available at run time and the server action is not accessed at build time.
well this doesn't seem to be what's happening, since you seem to be using utapi during render of a page so the prerendering fails.
Except it is what is happening. You can test it with the linked reproduction. If you're not convinced - this code produces the same error:
import { getImages } from "./uploadthing";
export default async function Home() {
return (
<main className="flex min-h-screen flex-col items-center justify-between p-24">
<button onClick={async () => {
const images = await getImages();
console.log(images);
}} />
</main>
);
}
And the endpoint is only called on a user action in that case.
The problem is that the check for the env variable is made when the utapi instance is instantiated, rather than when any of it's methods are called.
const utapi = new UTApi() // <- check happens here
To be clear, if I move the instantiation into the server action, rather than at the top level of the file, that would also solve the problem. This is a minimal reproduction though and in my somewhat more complicated use-case I really want to be able to instantiate it inside a library that is then used in my code.
To be clear, if I move the instantiation into the server action, rather than at the top level of the file, that would also solve the problem. This is a minimal reproduction though and in my somewhat more complicated use-case I really want to be able to instantiate it inside a library that is then used in my code.
That's fair, but in the repo you sent you had it like this:
https://github.com/4leite/utapi-mre/blob/67c57d73b7bc3baca7c8f6e1d2ce45a15018a3f0/app/page.tsx#L8
To get back to the point though, I can successfully build our with-serveractions
example without env vars, which seems to do the same thing as yours?
https://github.com/pingdotgg/uploadthing/blob/main/examples/with-serveractions/src/app/page.tsx
Yours do fail for me though, although I don't really see what's different 🤔
Yours has "use server" at the top level of the file, which causes subtly different behavior. My understanding is that will mean that the instantiation of the utapi is encapsulated within the created server action. It is equivalent to this:
export const getImages = async () => {
"use server";
const const utapi = new UTApi() // <- moving the instantiation here will build, but I want to avoid having to do that.
const { files } = await utapi.listFiles();
const { data } = await utapi.getFileUrls(files.map((file) => file.key));
return data;
};
This issue has been automatically marked as stale because it has not had any activity for 10 days. It will be closed in 5 days if no further activity occurs.
This issue has been closed because it has not had any activity for 5 days since being marked as stale.
Provide environment information
Describe the bug
I have a project on vercel with Uploadthing secrets set to 'sensitive' I build the project on another machine:
The build fails with the following error:
This is because the vercel sensitive secrets are not available on the build server at build time. The build should pass because the secret will be available at run time and the server action is not accessed at build time.
Link to reproduction
git@github.com:4leite/utapi-mre.git
To reproduce
git clone git@github.com:4leite/utapi-mre.git
initialise a new projectvercel
go to vercel dashboard and enter uploadthing credentials as sensitive secrets
Additional information
The is only an issue with 'utapi' I'm using the buttons and other features from https://docs.uploadthing.com/getting-started/appdir without any problem even though the secrets are not available at build time.
I can work around this by adding a fake key in the utapi config:
const utapi = new UTApi({ apiKey: process.env.UPLOADTHING_SECRET || "sk_" });
👨👧👦 Contributing
Code of Conduct