Best practice for working with Convex with background agents
For a project that uses Convex, what is the best practice when it comes to using background agents (like the cloud version of OpenAI Codex)?
The Convex dev server which handles code generation of API methods assumes interactivity.
And I can’t seem to get npx convex codegen to work inside of Codex. I always get the “fetch failed” error.
9 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!
Hey @Andric, I just pushed out an alpha with something that should work for this: using convex@1.26.0-alpha.4 and while logged out (like in a cloud dev enviroment; if you're logged in, run
npx convex logout first)
(you can set that environment variable in the config/setup for the environment)
Goal is for this to be able to run code / do codegen without needing to log in or contact convex.dev at all
Would love to hear how it works, I haven't used Codex yetThanks @ballingt ! Will test it out
@ballingt Thanks! I’ll try it out.
I think being able to run codegen in this way is definitely an improvement, but anyway we could run this but with some kind of bearer token passed in as an environment variable to login?
I’m not sure what’s the best practice for running the Convex server (so far I’ve been using the cloud dev environments rather than the local dev environments) non-interactively.
For example, to run integration tests or E2E tests with a real backend in CI or inside of the background agent.
Say more! You'd rather use a fresh cloud deployment for each CI run than a fresh local deployment it sounds like?
I'm on board but for prioritization (and improving local dev) would help to understand what's limiting about the local deployment
I’m not sure what’s the best practice for running the Convex server (so far I’ve been using the cloud dev environments rather than the local dev environments) non-interactively.Today the way to do this is to use a dev CONVEX_DEPLOY_KEY, but the problem is that that's your personal dev deployment so if you're developing at the same time you'll step on each other! So I'd like to make the local deployment flow work as well as possible, but also provide ephemeral cloud dev deployments for paid accounts. (pricing tbd because this is a new feature but that's the gist)
@ballingt Fair point about the dev environments not being ephemeral so they’re not good for testing.
I think it’s maybe just a lack of good docs for local envs so I don’t have a good grasp of how to set it up for CI and testing.
I’m still prototyping at the moment so haven’t written any tests, but I’d like to know how to set it up.
I use a self-hosted GitHub Actions runner for CI, and I’m not sure how exactly I’d go about setting it up to spin up an ephemeral local dev environment to run tests in (or its limitations vs cloud environments, as you say)
I’m used to doing this with PostgreSQL before: spinning up a container and then running tests on it, then shutting it down as part of the test runner
When I shut down the local env it should ideally be truly ephemeral (clears all internal state), and I should be able to choose when to stop this ephemeral environment, so I can orchestrate that on my test runner myself
I haven’t used Supabase in a long time, but I remember they had a nice CLI tool that internally spins up, using docker compose, the containers needed to run a local Supabase env, and you can start and stop at anytime, as well as pass in a flag to persist data on shutdown or not.
That was pretty nice DX, because you can use that for both CI and testing (where data persistence is set to false), as well as local dev where you want longer-lived environments.
Yeah we need to make this nicer (or for some situations, just possible), it's even better than a container typically because it's faster, just a binary.
Ah okay so there’s no good way to do it right now?
Preview deployments https://docs.convex.dev/production/hosting/preview-deployments are the way to go today, or
CONVEX_AGENT_MODE=anonymous to use a local deployment without it ever prompting (this is new with convex@1.26.0-alpha.7). Anonymous local dev deployments "scale" better (you don't need to pay convex for hosting them) but what needs to be nicer is a way to bring up cloud deployments, if you'd rather do that