Cloudflare Developers•13mo ago

Error deploying pages project to preview environment

Using wrangler 3.15.0, I cannot deploy my pages project to a preview environment. Using the following pages deployment command:

> wrangler pages deploy static --project-name=<REDACTED>
▲ [WARNING] Warning: Your working directory is a git repo and has uncommitted changes

  To silence this warning, pass in --commit-dirty=true


✨ Compiled Worker successfully
🌍  Uploading... (93/93)

✨ Success! Uploaded 0 files (93 already uploaded) (0.46 sec)

✨ Uploading Functions bundle
✨ Deployment complete! Take a peek over at <REDACTED>

> wrangler pages deploy static --project-name=<REDACTED>
▲ [WARNING] Warning: Your working directory is a git repo and has uncommitted changes

  To silence this warning, pass in --commit-dirty=true


✨ Compiled Worker successfully
🌍  Uploading... (93/93)

✨ Success! Uploaded 0 files (93 already uploaded) (0.46 sec)

✨ Uploading Functions bundle
✨ Deployment complete! Take a peek over at <REDACTED>

33 Replies

James•13mo ago

It sounds like you're running into https://github.com/cloudflare/workers-sdk/issues/3966, where your Functions are erroring after being uploaded

landonOP•13mo ago

so maybe a compilation error in the fuctions could be causing this?

James•13mo ago

not a compilation error, something at runtime specifically

landonOP•13mo ago

is there a log i could look at myself?

James•13mo ago

unfortunately there is not. If you post a deployment ID, I can ping someone tomorrow to take a look for you

landonOP•13mo ago

from the url looks like this could be the deployment id: 9604495b-8d76-4a37-890a-4131f5a6103e ok

looking forward to understanding more tomorrow

James•13mo ago

thanks, I'll ping someone to pull logs for you, sorry for the trouble Out of interest, does it work locally with pages dev? That might be a way you can shortcut figuring this out if it errors there too

landonOP•13mo ago

yeah sure does

James•13mo ago

that's no fun, sorry. Hopefully the logs will yield more info

landonOP•13mo ago

well, getting an issue with 3.15.0 that im not getting with 3.4.0

Error: D1_ERROR: no such table: dashboard_notifications

Error: D1_ERROR: no such table: dashboard_notifications

there any issues w/ d1 bindings that could be causing this? (ive tried to deploy with 3.4.0 as well)

James•13mo ago

not to my knowledge 🤔 you might try asking in #d1-beta some logs were pulled for you @landon : could not resolve binding "BUILD_SCHEDULER" something about your service binding config is incorrect double check your environments and everything there is setup correctly

landonOP•13mo ago

Will do thank you! i checked to make sure its bound through the UI. i selected "production" but its linking to a staging version (our worker is confusingly named build-scheduler-staging)
https://dash.cloudflare.com/e7526284f9ee484875c61723e78af4ae/workers/services/view/build-scheduler-staging/staging i get a 404 from that link, but f i replace that last path parameter of "staging" with "production" it resolves

James•13mo ago

hmmm, is build-scheduler-staging a very old worker that uses service environments or something like that? What's your account ID? dumb question, it's in your url above e7526284f9ee484875c61723e78af4ae 😅 what happens if you try and edit the binding and point it to the production env? (service environments were an old thing that's since legacy, so every worker has a production env that's just default nowadays)

landonOP•13mo ago

I tried that it had no effect The link still pointed to staging

James•13mo ago

Can you check the payload being sent from the dash when you make that change, in your browser's network reqs?

landonOP•13mo ago

Sorry I had to step away I can check in about 10 min little disparity here between what im sending, and what im receiving check it

{"deployment_configs":{"preview":{"services":{"BUILD_SCHEDULER":{"service":"build-scheduler-staging","environment":"production"}}}}}

{"deployment_configs":{"preview":{"services":{"BUILD_SCHEDULER":{"service":"build-scheduler-staging","environment":"production"}}}}}

and then in the response i see:

...
        "services": {
          "BUILD_SCHEDULER": {
            "service": "build-scheduler-staging",
            "environment": "staging"
          }
        },
...

...
        "services": {
          "BUILD_SCHEDULER": {
            "service": "build-scheduler-staging",
            "environment": "staging"
          }
        },
...

James•13mo ago

oookay I think we're getting somewhere. Can you try entirely removing it, save, and then re-add, and save again? I think there's a bug there that's pending a fix but it hasn't landed yet

landonOP•13mo ago

yeah i tried to do that, but i did it in one shot, hold on let me try again ins eparate steps ok response looks better, let me try to redeploy success! thank you

James•13mo ago

awesome!

kingmesal•13mo ago

There is an inconsistency in the API implementation and docs. When doing wrangler deploy --env staging on my function name test it creates the worker as test-staging, but based on this, it seems like the worker should be deployed as name=test with env="staging" What is the process to get these 2 sides synced up?

Chaika•13mo ago

Sounds like you're confusing Pages and Workers? This is the Pages help forum. Pages have full blown environments, prod & preview for the same pages project. Workers don't, they used to have something like it, but now it just works like you've reported -- by creating separate workers Please make your own #workers-help thread if you need help, don't hijack others

kingmesal•13mo ago

Thanks for that, but I'm not. A pages project can depend on a worker through a service binding. That binding naming / env is the problem. There are numerous problems between the names / env as well as the API for creating bindings. It starts with deploying a worker (aka service) -- let's call it test wrangler deploy --env staging This results in a worker being deployed named test-staging If you then try to add a 'service' binding to your pages project via the API https://developers.cloudflare.com/api/operations/pages-project-create-project The docs incorrectly say:

      "service_bindings": {
        "SERVICE_BINDING": {
          "environment": "production",
          "service": "example-worker"
        }
      }

      "service_bindings": {
        "SERVICE_BINDING": {
          "environment": "production",
          "service": "example-worker"
        }
      }

Now check the wrangler docs: https://developers.cloudflare.com/workers/wrangler/configuration/#service-bindings It has a correct layout which is:

      "services": {
        "SERVICE_BINDING": {
          "environment": "production",
          "service": "example-worker"
        }
      }

      "services": {
        "SERVICE_BINDING": {
          "environment": "production",
          "service": "example-worker"
        }
      }

EXCEPT, that doc says environment is optional, but via the API it is not optional. It is required. Now if you deployed the test worker into staging you might think that service test with environment staging is correct, but that worker wont' exist because it was deployed as test-staging. If you specify service as test-staging and environment as staging that also will not work because when that worker was deployed the actual behind the scenes environment was set to production. I would consider this to be a pretty big inconsistency that should get resolved ASAP. I raised a support issue on the API doc inconsistency, but had not yet experience the pages -> service binding environment issue. https://support.cloudflare.com/hc/en-us/requests/2938937 But this problem is worse than just an inconsistency in the docs, because this is an implementation inconsistency in wrangler and pages services references.

Chaika•13mo ago

Again, that's just how workers work. They have no environments, those are a relic of the past, always production these days. You can specify different service bindings for each pages environment, ex example-worker for prod, example-worker-staging for preview James has a pretty good summary on that all with Workers, let me see if I can't dig it up https://community.cloudflare.com/t/environments-vs-deployments/451036/2?u=chaika it is a bit confusing to be fair There is ongoing work to make that simpler with convergence of pages & workers: https://blog.cloudflare.com/pages-and-workers-are-converging-into-one-experience/, but still a while out afaik

kingmesal•13mo ago

I understand what you are saying... then the docs need to get corrected and environment on the pages service bindings should be removed because it can ONLY be production

Chaika•13mo ago

The thing is really really old workers can still have environments, you just can't set them anymore on new workers, so it's a bit more complex then that, I just simplified it a bit

kingmesal•13mo ago

okay... then why do the docs not reflect that information

Chaika•13mo ago

hmm, where? I can't view support tickets, if the details are in there The docs are also open source, might just be redirected/could just create an issue there

kingmesal•13mo ago

the links I just shared to wrangler and the API docs

Chaika•13mo ago

oh, just that one field being optional when it's not?

kingmesal•13mo ago

it may be optional in the wrangler toml, but it is not optional in the API call and using --env with a worker doesn't align with environment in the service binding api call

Chaika•13mo ago

oh, does the api docs show it optionally? Doesn't look like it does

kingmesal•13mo ago

the api doc doesn't show it as optional or required it just shows the example but the mismatch in these details leads to an error when deploying the pages project where it says it deployed but then the pages project in the dashboard shows an error deploying so look ... at this point, aside from something changing how this implementation works, I now know how it works. I won't make the mistake again. It is much more likely to affect others because those documentation terms / details do not align with one another.

Chaika•13mo ago

ah ok, sounds like it is a bit connected to this if Pages doesn't instantly throw an error on deploy but does in the dashboard, that is a bit rough Pages API Docs in general are a bit rough around the edges, but it sounds like there the wrangler.toml just takes a different way from the pages api and has that optional afaik both the environment and workername should be marked required under that service binding object, object itself is optional, but both fields aren't, you already submitted a ticket about it, but you could also use the give feedback button on the bottom left of the api docs

Gaming

Programming

Error deploying pages project to preview environment