Branching - Early access | Feedback discussion

[MildTomato]

This discussion is for tracking feedback and possible issues for Supabase Branching.

This will help us plan a roadmap for the feature going forward.

Vote for hosting provider integrations here and Git providers here.

[bitnom]

This discussion is for tracking feedback and possible issues for Supabase Branching.

This will help us plan a roadmap for the feature going forward.

What is Supabase Branching?

[MildTomato]

In the most concise sense, you can use branching to safely and easily experiment with changes to your Supabase projects.

You can check out the docs here.

[KajSzy]

Is branching expected to be available only from Pro plan or will it be availbe on free tier?
If I decide to upgrade to Pro plan today, will I be able to use branching immediately?

[MildTomato]

@KajSzy We've currently closed the Early Access programme for Branching. If you have already upgraded expecting access, if you could send in a support request and we'll look into it 😄.

I think some of our docs have not been updated to make it clear that it's in private early access, and we've now closed accepting any more requests. I'll update the docs today to be more clear.

[skarard]

Hope you're all doing great! I've been working with supabase on a project for 2 months and noticed something I wanted to share with you that would cause issues for supabase branching. As our projects grow, our seed file (you know, the trusty seed.sql) can become a bit of a beast. We're talking thousands of lines that make you not want to open it up again. In my case, it has ballooned to over 10K lines! Runs pretty fast, sure, but it's a bit of a headache to manage and scroll through.

I've been sidestepping this by ditching the massive seed file and scripting my local database seeding instead. It's a lot like how migrations work: each file is timestamped and has a quick description, and they run in a set order. This means I have separate files for different seeding needs, like permission tables and location table inserts broken down into 1K-insert chunks – it’s pretty neat.

Currently, Supabase runs whatever is in seed.sql and that's that. But here’s a thought: what if branching could also run all the timestamped files we've got in a seeds folder? I think that'd be a game-changer for many of us, making life a bit easier and our projects tidier.

I reckon this could be something worth considering for your roadmap for seeding a branch.

Thanks for all the hard work you've been putting into Supabase, and I'm excited to see how branching evolves!

[MildTomato]

Neat idea.

I also mentioned this to @sweatybridge who is one of the developers managing our migration/seed runner.

I suppose it would have to be timestamped for it to work correctly. Do we know of any other tools doing this? We can't be the first ones to think of this? 😊

[skarard]

To be honest I took the idea directly from my experience of working with the ORM Sequelize. Here is a relevant documentation that mention both migrations and seed files: https://sequelize.org/docs/v6/other-topics/migrations/

One thing to note is that their migrations have an up (which is covered by seed.sql) and a down that is not covered by supabase. The down function is if you are to roll back a migration including any data manipulation that was required to complete the migration. It's very useful when you can't predict how a project will evolve once it's in front of users. Sequelize also handle transactions in their migrations, which makes migrating production databases a lot less intimidating.

[MildTomato]

There is a similar discussion to this here as well now 🙌

[chaos128]

if new branch is created, new Supabase url for client is reserved on new branch??

I maen if I use following url on main branch
const supabase = createClient('https://xyzcompany.supabase.co', 'public-anon-key')

Can I use a different url for a new branch like staging? For example,
const supabase = createClient('https://xyzcompany.supabase.co/staging', 'public-anon-key')

[MildTomato]

How it works today is a bit like that but it's the id string in the middle that changes.

main branch (production)

const supabase = createClient('https://spztrrugbkgdayfejlvi.supabase.co/', 'public-anon-key')

the feature branch your working on will then have a completely different id in the url

const supabase = createClient('https://qrelykancvxikefwrefd.supabase.co/', 'public-anon-key')

I could understand if this might not be useful in some circumstances, as it makes it harder to build urls based on git branch name in maybe your client or server app.

The problem extends to API keys though as well, since every branch in Supabase has it's own unique set of API keys, db password and so on.

What do you think @chaos128 ?

[chaos128]

It would be okay but I think it would be a little bit inconvenient. It would be better if domain and key are not changed but only pathname is changed based on branch names like I said on question.

main branch
const supabase = createClient('https://xyzcompany.supabase.co/', 'public-anon-key')

staging branch
const supabase = createClient('https://xyzcompany.supabase.co/staging', 'public-anon-key')

feature/test branch
const supabase = createClient('https://xyzcompany.supabase.co/feature/test', 'public-anon-key')

[MildTomato]

That's interesting. Can see that being a lot more useful and easier to use.

Also the keys not changing between Preview Branches is interesting as well - we were mostly concerned with Production and Preview being isolated and concentrated efforts on that and hadn't really investigated on making it easy to switch between Preview branches with predictable URLs and consistent keys. Great suggestion.

[MildTomato]

@chaos128 how are you using Supabase Branching?
are you running your app locally and trying to easily connect to correct Preview Branch?

[rorysaur]

Chiming in here because I would also love to see predictable URLs and consistent keys.

We have a Next.js app on Vercel, using Prisma. Our current workflow, without Supabase branching:

Our branch main syncs to our Vercel staging deployment and uses our Supabase staging db. Our branch production syncs to our Vercel production deployment and uses our Supabase production db. We have a GH action which, upon merge to either of these, runs prisma migrate against the respective db, using creds stored in GH secrets.

That means preview/feature branches create Vercel preview deployments, but have to stay unmigrated (except for staging itself), since we don't want to mess up the staging db before merging to main. So features requiring migrations can't be tested on a preview deployment.

If we turned on Supabase branching on our staging db, I'm picturing that it could work for preview deployments if the app and, separately, the GH action, can both get or construct the branch db's URL/creds (actually we use the full pooler URL) from env variables that are available. And then we'd have the GH action migrate the designated branch db upon branch creation. So a completely new set of URL/creds seems hard to deal with in this scenario, whereas some combination of base URL (already set in Vercel and GH) plus the branch name (already easily available in Vercel and GH) would be very doable.

I see someone else who posted has a similar setup with some steps to make it theoretically work in the GH action.. but it seems to rely on CLI commands, and I'm not sure if that would work for getting the Vercel preview app to also point to the branch db.

(Update: I also just realized Vercel support is in development which would solve the Vercel half.)

[sudonymously]

Can branching be used as a "dev" environment?

[MildTomato]

Yep. What's your use case? Can you tell us more?

[kishanhitk]

According to the docs: "The database is only seeded once, when the preview branch is created. To rerun seeding, delete the preview branch and recreate it."

But when I deleted and recreated the branch (dev), it does not recognise the existing PR from that branch.

[kishanhitk]

EDIT:
The branch migrations are being applied as expected. Only this UI on the dashboard is not being updated properly.

[MildTomato]

That's probably a bug. We are using github webhooks and I think it only adds the PR metadata to the Preview Branch when a PR is opened (there's a webhook event for it) - but that makes it impossible for a new Preview Branch to then be associated with a PR later; like when you've made a new Preview Branch.

I think we could fix that. Everything should work as normal though, it's only the UI here that's been impacted.

[0xBigBoss]

So far pretty good with supabase branching. Should I disable my existing github actions that migrate the production database when merging to the production branch? Is it expected that the migrations should be applied via this new Supabase branching integration?

reference https://supabase.com/docs/guides/platform/branching?making-updates=local-dev#merging-production-changes

[MildTomato]

It's worth stressing first that Branching is not suitable for production based apps right now.

With that in mind, and if you want to continue; yes, you should be able to merge your feature git branch into your 'production' git branch and it will run the new migration files against the Production Supabase branch. There is currently no way to turn this off, so it's probably advised to disable your github actions.

[huyouare]

@MildTomato are there known issues we should watch out for w.r.t. production? Or is it just that more time is needed to bash the bugs out that in theory could harm a prod instance?

[blechatellier]

@MildTomato does supabase branching support monorepos? Our supabase/migrations folder is in a subdirectory (ie: apps/database/supabase/migrations.

[kamilogorek]

Changing a path which /supabase is pulled from is on our roadmap. However as @MildTomato already mentioned, we need to rethink how it works first, to allow multiple Supabase projects to read from a single repo (eg. your monorepo usecase) or any other variant of one-to-many/many-to-many connections.

[tristdrum]

Yeah would love to see this sort of mono-repo support! Very excited for you all to start using branching on internally too!

[donjpierce]

I would also require the mono-repo support for my project with a custom path to my migrations folder. Big fan of this branching feature and how it is progressing!

[kamilogorek]

The code for it is already written and we're going to test everything in upcoming week :)

[kamilogorek]

Monorepo support has been added and is already live if you have an access to branching 🎉

[mosnicholas]

any advice on how to handle issues like this that require setting up things in the database (eg. webhooks)?

[danielgwilson]

Any updates here? This is preventing us from using branching

[danielgwilson]

@MildTomato

[blechatellier]

For what it's worth, I have been running into so many issues with branching that the best solution for us was to manage the full lifecycle using a custom github action leveraging the management API.

[danielgwilson]

@blechatellier that may be what we have to end up doing—would be a shame

[blechatellier]

To be fair, hard for them to come up with something that will work for everyone - it's been the best decision and took a couple of days to get it to work.

[hyldmo]

Hello! Loving the concept so far. After spending some time working around issues (seeding not being run and functions not being deployed), I realised you have a CLI for managing branches (which looks great btw!), and I think it could be highlighted more, as I was under the impression that only the "managed" workflows were supported (i.e only Github + Vercel), but atleast for me the feature set is complete enough that I could run this anywhere (and if i missed that that was possible, many others probably have too)

[MildTomato]

Just checking, as we need to improve our documentation:
Did you follow this guide regarding preparing your repo?

[sleakchat]

@hyldmo How did you manage to work around the issue of webhooks not being able to deployed in preview?

I'm experiencing a similar issue, when migrating everything migrates succesfully except for the existing database webhooks:

Connecting to remote database...
Applying migration 20240413231739_remote_schema.sql...
ERROR: schema "supabase_functions" does not exist (SQLSTATE 3F000)                                                                                                                                                                                                              
At statement 80: CREATE TRIGGER "new_kb_topic" AFTER INSERT ON "public"."kb_topics" FOR EACH ROW EXECUTE FUNCTION "supabase_functions"."http_request"('my-url', 'POST', '{}', '{}', '5000')
Try rerunning the command with --debug to troubleshoot the error.

[venku122]

+1 I am also running into this issue.

I went to /database/hooks on the preview branch and enabled webhooks.
Retriggering a deploy did resolve the issue.

[sweatybridge]

My "dream" CI workflow would work something like this:

1. Run supabase branches create $BRANCH_NAME
2. Get project ID from newly created supabase branch
3. Use project ID run regular steps:
4. supabase db push/reset
5. Run codegen off branched supabase instance
6. Run linting / formatting / unit tests
7. Build and deploy frontend with project ID
8. Deploy supabase functions
9. Verify env with E2E tests

If you are willing to manage your own GHA for setting up branches, all of the above are currently available through the terraform provider. We have an example repo here for those who want to tweak and use https://github.com/supabase/supabase-action-example/blob/main/.github/workflows/preview.yaml

I went to /database/hooks on the preview branch and enabled webhooks.

For webhooks, we will look into enabling by default for all new projects and branches.

[danielgwilson]

@sweatybridge any updates on Webhooks?

[DamonGuzman]

We are in dire need of selecting non root directories as the Supabase root. We are using a monorepo with TurboRepo.

[kamilogorek]

It's coming. Bear with us some more time, we're getting there :)

[DamonGuzman]

That's great news! We just finished building our own internal psuedo-branching by creating a new project on every PR. It was quite difficult to implement correctly since there was a silent failure when connecting via IPv4.

Do you have any rough estimation on timelines?

[kamilogorek]

We're hoping to release this month, but I don't want to be held accountable for any specific date just yet.

[kamilogorek]

Monorepo support has been added and is already live if you have an access to branching 🎉

[sidharthv96]

Currently, we're testing each branch by setting up a local supabase instance in GH Actions for every run. But that setup takes a significant amount of time compared to the actual test run.
So we're looking for a way to accelerate the setup process, using branching.
We have our seeding script in TS, and are using Prisma for migrations, and use Vercel for deployment.

The flow that we have in mind is:

1. Inside GH Actions, on PRs
2. List all branches using supabase CLI
3. Create preview branch if required
4. Get the details of the preview branch using CLI (URL, API key, etc.)
5. Update our .env file with the details, clear, migrate and seed the database (to be consistent across runs)
6. Run the tests
7. When PR is merged, use supabase CLI to delete the preview branch

Are there any blockers that we should be aware of?
Is there a better way to do this?

Moreover, once this is set up and the Vercel app is used, I'm assuming the preview instances will use the new branched supabase.

We also don't want any changes in the preview branches going back into main (which I assume will not happen as we are not using supabase migrations in the preview branches). Can you please confirm this?

[sweatybridge]

which I assume will not happen as we are not using supabase migrations in the preview branches

Yes that is correct. The Supabase GitHub integration only look for files in supabase/migrations directory. If it is empty, no migrations will be run.

Overall your approach sounds sane to me.

We will need to make some changes for step 2 and 3 so that you can fetch a preview branch by its git branch name. Otherwise the current workaround is to parse the output from branches list command to extract the branch id. Then use pass the branch id to branches get command.

You might also need to handle retries in step 4 until the status of your branch database is ACTIVE_HEALTHY.

I think step 7 is not required if you use the Supabase GitHub integration. Because we delete the branch on PR close.

[thedevdavid]

Feedback/idea: It'd be nice (or even crucial) for the preview branch to copy most local and/or production branch settings.

Examples:

• custom email templates (because you need to customize them for Next.js SSR)
• use the production API endpoint with a subdomain or route for preview branches
• auth site & redirect URLs
• auth provider settings
• project auth settings (custom SMTP included)
• upload size limit
• edge function secrets (or at least some prompt to set them)

[Tananga]

This is a must have

[MarkBennett]

Given the branching is meant to correspond with git branches, perhaps moving all these settings into the supabase folder and then letting you change them in the filesystem would make sense?

That would let teams modify using their existing git workflow, and handle these decisions there?

[sweatybridge]

perhaps moving all these settings into the supabase folder and then letting you change them in the filesystem would make sense?

This sounds like a configuration as code proposal. We have a terraform provider example where all the auth and api settings are committed to git. https://github.com/supabase/supabase-action-example/blob/main/supabase/remotes/preview.tf

In the long run, we probably want to support copying configurations from base project so that we don't explicitly depend on terraform in the infrastructure.

[empz]

Any updates on this? Without the Auth provider settings this is unusable as we have to go over and manually enable providers for each preview branch to be usable. Because auth provider settings are not stored in the database, or are they? I mean, we couldn't set them in a migration.

[Keeghaan]

Any updates ? This idea is really necessary

[ronthedrummer]

For some reason I'm not seeing migrations running or seed data populated for a preview branch (feature or development). When I create a PR, it's spinning up the branch, just no tables or seed data.

[kamilogorek]

When creating a new branch on Github, it doesn't mean I want to create a new branch on Supabase automatically. Only when there are changes in the ./migrations folder I'd say. Or make that arbitrary.

Done, you can use it today.

Option to have the data populated in an easy way

There is basic seeding capability already with seed.sql file, but we want to add better integration with Snaplet or similar tool as well in the future.

[morasaek]

Whenever I merge branches, the branch disappears. I think this might be useful when working with feats, but when you want a permananent staging branch, it's not desired.

+1(00) on this point!

[RobSchilderr]

They say the best way now is to create a separate Supabase project for the staging branch.

[kamilogorek]

Q: We have few ideas how to go around it, but just to get a feel for it in public, wdyt is your preference in regards to long-lived branches?

• hand-pick already existing branches to be persisted, eg. on branches page - https://supabase.com/dashboard/project/_/branches
• change the setting to be applied for a whole connection on - https://supabase.com/dashboard/project/_/settings/integrations
• have a connection setting where you can list branch names to be persisted
• other approach?

[huyouare]

Adding a data point: we are using a separate project for Staging + Preview branches, while keeping our original project for Production only (same as @RobSchilderr's post above). This seems to work pretty well for persisting Staging so far, though it's not 1:1 with the Vercel style of branching.

[amitav13]

We handle our migrations via Prisma migrate. Are there any plans to support the migrations folder generated by this? Or any workarounds at this point?

[kamilogorek]

Currently you'd have to move file to migrations directory inside ./supabase, but that's a good improvement for the future. Thanks

[amitav13]

Would just moving the folder work? The migration files/formats are directly compatible with supabase?

[kamilogorek]

Yes, the migration file is always just a smallest sql snippet that will result in the desired schema shape at the end of execution.
They are usually tracked via sorted list of migration files, that are stored in _migrations (or similar) table.
The only difference here is that prisma expects migration files path to be migrations/data_name/migration.sql file, eg migrations/20210313140442_init/migration.sql, where Supabase expects migrations/20210313140442_init.sql, which means that you'd have to do something like code below to copy, rename and put them in correct place in one go.

find . -type d -depth 1 | xargs -I{} cp {}/migration.sql migrations/{}.sql;

[amitav13]

Got it. A cleaner way built in to supabase would be nice! Especially since there's a pretty large audience (I'm assuming) of supabase TS users using prisma.

[aliyeysides]

Here's a bash script for those that want to copy Prisma migrations to a supabase directory:

#!/bin/bash

# Define paths
PRISMA_MIGRATIONS_DIR="./prisma/migrations"  # Replace with your Prisma migrations directory
SUPABASE_MIGRATIONS_DIR="./supabase/migrations"  # Replace with your desired Supabase migrations directory

# Create the Supabase migrations directory if it doesn't exist
mkdir -p "$SUPABASE_MIGRATIONS_DIR"

# Function to convert Prisma migration files to Supabase format
convert_prisma_to_supabase() {
  for prisma_migration_dir in "$PRISMA_MIGRATIONS_DIR"/*/; do
    if [[ -d "$prisma_migration_dir" ]]; then
      migration_file="$prisma_migration_dir/migration.sql"
      if [[ -f "$migration_file" ]]; then
        migration_name=$(basename "$prisma_migration_dir")
        supabase_migration_file="$SUPABASE_MIGRATIONS_DIR/$migration_name.sql"
        cp "$migration_file" "$supabase_migration_file"
        echo "Converted $migration_file to $supabase_migration_file"
      fi
    fi
  done
}

# Run the conversion function
convert_prisma_to_supabase

echo "Migration conversion completed."

[UmashankarSpeckyfox]

Hey Folks

I want to Setup a Supa Base Branching for the Automation Testing so the scenario is Below
I need to Setup the CI/CD pipeline for the Automation Project. Pipeline is already exists but i need to run my tests in between build and Deploy. So i want to use a Supabase branching to run my automation scripts on supabase temporary branch.

So how i can do it can anyone help me out in this

Thanks in Advance.

[gc-ft]

Small bug: If you have more than one vercel project integration, saving does not work correctly. If I change something in the second and press Save there, the Save in the first integration runs. I can not turn off production env keys for the second integration now.

[gc-ft]

Tried PR first time with changes in migrations. Branch Preview is created in supabase, but the migrations fail and the only error I see in the logs on GitHub is:

failed to run supabase --workdir=.: 1

There is a warning also in the GitHub PR comments, however this seems out of my control:

 Warning — Preview branch version (15.1.1.86) does not match production database version (15.6.1.113).

Amy ideas?

Thx,
Fabian

[gc-ft]

My problem was that webhooks were disabled and a create trigger using supabase_functions failed.

I will move away from the internal webhooks logic to my own soon, so that should fix that issue.

However, should the GitHub integration not produce a more intelligent error showing WHERE the migrations actually failed?!

Fabian

[Jullemand]

When setting up my development branch next to my main branch I run

supabase db pull --db-url postgresql:// URL /postgres

Here I then get the following error:

failed to parse rows: ERROR: prepared statement "lrupsc_1_0" already exists (SQLSTATE 42P05)

I have no migration files. I have tried to remove the /supabase folder, /migrations folder, re-init and revert to older migrations when I had some. My supabase CLI is up to date.
Any ideas on what to do?

[kamilogorek]

Can you verify that you're actually using postgresql://...:5432/postgres url instead of a pgbouncer postgresql://...:6543/postgres?

[Jullemand]

Thank you for your fast response two weeks ago.
Your comment solved it, I just forgot to respond! Thank you! :D

[spencer-rafada]

How can I configure Supabase to not show up as unsuccessful action when there are no changes to supabase directory at all?

[gc-ft]

There is an option in settings > integrations under the GitHub integration uncheck the "supabase changes only"

That should work.

How can I configure Supabase to not show up as unsuccessful action when there are no changes to supabase directory at all?

[kamilogorek]

@spencer-rafada I assume you have a required status check configured in this case? As we don't create status checks on our own for not matched PRs.

[slimshreydy]

I need to access my branch DB instance via an old-school connection string (I'm using it with an ORM). It seems like the DB instance has its own separate password, but it's not a password I've set anywhere. How can I locate the password Supabase generated with the branch?

[kamilogorek]

Use https://api.supabase.com/api/v1#tag/environments/GET/v1/branches/{branch_id} to fetch branch configuration. You can find generated password there.

[leon-endex]

How do we increase the compute/memory for supabase preview branches?

[kamilogorek]

There is currently no way to do this, and all branches are running on Nano instance.
Our branching team is working on allowing that and providing custom config for branches as we speak. I cannot give you any specific timeline though here.

[sapoepsilon]

We have three projects in supabase - qa, test(staging) and prod. Whenever there is a merge to Github's main branch the test project uses supabase branches we apply migrations to qa and prod projects via GitHub Actions . We create a new supabase branch on our test project, on a new Github PR againt the main branch. Our issue is once we merge that PR, the migrations(sometimes) are not merged to our supabase test project's prod branch.

Has anyone had that issue? Right now we have to use three GitHub Actions, that basically does supabase db push to fool proof our migrations.

EDIT: To illustrate my supabase migrations:

GitHub:

You can see the discrepancy, and it is causing a lot of issues for our dev team.

[sapoepsilon]

We ended up implementing this GitHub action as a fail-safe mechanism.

  deploy-supabase-testing:
    if: ${{ needs.check-changed-files.outputs.supabase_all_changed_files != '' }}
    needs: [check-changed-files]
    runs-on: ubuntu-latest
    env:
      SUPABASE_TESTING_PROJECT_ID: ${{ secrets.TESTING_PROJECT_ID }}
      SUPABASE_DB_PASSWORD: ${{ secrets.TESTING_DB_PASSWORD }}
      SUPABASE_ACCESS_TOKEN: ${{ secrets.SUPABASE_ACCESS_TOKEN }}
    steps:
      - uses: actions/checkout@v4
      - uses: supabase/setup-cli@v1
        with:
          version: latest
      - run: supabase link --project-ref $SUPABASE_TESTING_PROJECT_ID
      - name: List all migrations to be applied
        run: supabase db push --dry-run --include-all
      - name: Apply all migrations
        run: supabase db push --include-all
      - name: Deploy Supabase Edge Functions to Production
        run: supabase functions deploy --project-ref $SUPABASE_TESTING_PROJECT_ID
  deploy-supabase-testing:
    if: ${{ needs.check-changed-files.outputs.supabase_all_changed_files != '' }}
    needs: [check-changed-files]
    runs-on: ubuntu-latest
    env:
      SUPABASE_TESTING_PROJECT_ID: ${{ secrets.TESTING_PROJECT_ID }}
      SUPABASE_DB_PASSWORD: ${{ secrets.TESTING_DB_PASSWORD }}
      SUPABASE_ACCESS_TOKEN: ${{ secrets.SUPABASE_ACCESS_TOKEN }}
    steps:
      - uses: actions/checkout@v4
      - uses: supabase/setup-cli@v1
        with:
          version: latest
      - run: supabase link --project-ref $SUPABASE_TESTING_PROJECT_ID
      - name: List all migrations to be applied
        run: supabase db push --dry-run --include-all
      - name: Apply all migrations
        run: supabase db push --include-all
      - name: Deploy Supabase Edge Functions to Production
        run: supabase functions deploy --project-ref $SUPABASE_TESTING_PROJECT_ID

Kinda disappointed that we need to rely on this, and that migrations are not merged on PR merge.

[slimshreydy]

Anyone else running into an issue where branches don't close automatically after their associated PR is closed/merged? Causing me to pay a lot in unnecessary compute....

[sweatybridge]

Could you reach out to support? We can evaluate your case to see if it's eligible for refund.

[josematute]

seed.sql Not Working in Supabase Branch Created via GitHub Workflow

Hi everyone,

My team experiencing an issue where the seed.sql file isn’t working when I create a Supabase branch using my GitHub workflow. The migrations seem to be applying correctly—I can see them in the Supabase Studio UI for my branch —but for some reason, the seed.sql file isn’t executing.

The supabase workflow seem to have worked correctly given the Supabase bot comment:

Here’s the error I’m encountering when I go to Logs->Auth:

{"level":"fatal","msg":"running db migrations: Migrator: problem creating schema migrations: couldn't start a new transaction: could not create new transaction: failed to connect to \host=localhost user=supabase_auth_admin database=postgres: dial error (dial tcp 127.0.0.1:5432: connect: connection refused)","time":"2024-10-15T21:31:58Z"}

Has anyone else faced this issue or have any insights into what’s going on? We’re wondering if it’s something we’ve introduced or if there’s another explanation. Any help would be greatly appreciated!

[hatedabamboo]

Experiencing the same issue: feature branch in Supabase being created successfully with all the necessary migrations, but seeding doesn't execute, the tables remain empty.

[sweatybridge]

I can confirm this is a bug. We will look into fixing seed next week.

[josematute]

@sweatybridge thanks!

[sweatybridge]

Update: we have released a fix for this issue.

[josematute]

Update: we have released a fix for this issue.

@sweatybridge TYSM!

[josematute]

UPDATE ⚠️ : This is not happening anymore.

We are having an issue in which when we create a PR, the Supabase branch workflow starts but never end. This just started happening. We are not having any migration problems when we run supabase db reset locally.

Here is how it looks like in the PR page:

And if I click the Supabase workflow, here is what it shows, including thats it has been running for almost 30 mins:

The preview branches do get populated and listed in the studio UI:

But when I press view logs, nothing is shown:

[icopp]

I've run into repeated cases where the logs end in:

(on main)

2024/10/23 00:18:23 INFO All migrations are up to date.
2024/10/23 00:18:23 INFO Skipping seed data on protected branch...
Updating Storage bucket: (bucket name)
2024/10/23 00:18:25 Error status 400: {"statusCode":"413","error":"Payload too large","message":"The object exceeded the maximum allowed size"}

(on a branch)

Seeding data from (filename)...
Updating Storage bucket: (bucket name)
2024/10/23 17:28:40 Error status 400: {"statusCode":"413","error":"Payload too large","message":"The object exceeded the maximum allowed size"}

Any idea what's going on?

[sweatybridge]

This error message is confusing but it's actually due to misconfigured bucket size. We have released a fix so that the settings declared in your config.toml will apply correctly. For eg.

[storage]
file_size_limit = "50GiB"

[Raj1v]

Is it possible to add Edge Function secrets? Right now, it seems the only workflow is to copy secrets from the main branch manually..

[MorganFrary]

It seems like import_maps aren't being used for deploying edge functions - I keep getting relative import errors (It's not using the import_map.json and is therefor interpretting some of the imports as relative).

The functions deploy perfectly fine when deployed manually (supabase functions deploy) or through a custom CI, or when I explicitly define the import url in the edge function (e.g import 'z' from 'https://deno.land/x/zod@v3.23.8/mod.ts') just not via branching.

The import map is in the "correct" folder as described in the docs (functions folder)

I did manage to find a fix, but it's less than ideal - explicitly defining the import map in the config.toml, per function, like so:

[functions.hello-world]
import_map = './functions/import_map.json'

[sweatybridge]

Hello, declaring a function specific import_map in config.toml is recommended for deployment because it reduces the size of each function and keeps them isolated from each other. Using a shared import map also works but without the benefits.

[MorganFrary]

Hi, thanks for your response.

I can understand the motivation, however the docs explicitly describe this folder as being preferable and it's already being pulled in automatically by supabase functions deploy. This means that behaviour between branching and standard function deployments is inconsistent, I don't see this documented anywhere in the supabase branching docs so the default behaviour is unexpected from a developer perspective.

I'd suggest that this be added to the documentation so it's at least clear that this is the intended workflow.

[MorganFrary]

@sweatybridge I just spotted you've updated the docs regarding import maps in favour of deno.json - really appreciate you guys jumping on this so swiftly :)

[rcuevas01]

Hi! I'm running into an issue and looking for some help.

I have my prod (main) db to be connected to my main branch for my project on Github, and I have a branch for dev as well that's connected to my dev github branch. When I put the environment variables in my local env file, everything runs as normal, but when I paste them into Vercel, Supabase is missing an auth session and not allowing me to do any authentication on the Vercel links.

Could this have something to do with the branching? This did not happen before I set up branching on Supabase. I copied the DB schema from prod to dev, so they are the exact same, but I have not done anything else on the command line, and I'm not sure if I need to. Any help would be appreciated, and I can add clarifications as well!

[oleksify]

This is probably because the auth hook needs to be manually applied on new branch after it is created. I have the same problem. I tried writing to support because we have Pro account but there was no response...