New deployment failed about wildebeest HOT 58 CLOSED

That is likely you have deployed rules in the past through the dashboard UI, hence an entrypoint ruleset had been automatically created by the UI behind the scene. Tested that you need to call the API https://developers.cloudflare.com/api/operations/zone-rulesets-delete-a-zone-ruleset to delete that entrypoint ruleset, then it can be managed by Terraform.

@xmflsct that did the trick, but for the record, the error wasn't due to any ruleset that I deployed, it was actually the orphaned wildebeest ruleset from an earlier (failed) run. Until the UI updates are shipped (h/t @xtuc), I would strongly recommend adding a CF API call to your deployment that checks whether the managed ruleset bypass already exists.

In fact, you'll probably need to do that for several steps along the Terraform deployment script in order to fix the numerous errors that trigger deployment failures due to pre-existing resources (see the comments from myself and others above). In the absence of such changes, I don't see how we won't keep running into these deployment roadblocks every time there's a substantive change to the project's infrastructure.

from wildebeest.

I just discovered this issue on my first attempt.

Including Images, you also have to subscribe to Workers Paid plan. Durable Objects is only accessible in the Workers Paid plan.
Cloudflare Images $5/month min. Cloudflare Workers Paid- $5/month min.

Based on the Readme, I had buy in with $5/month. Unfortunately, I don't have buy in to do $10/month just for Wildebeest.

I'm stoked that Cloudflare is contributing to the ActivityPub community. Sorry Cloudflare team, I won't be participating.

from wildebeest.

To delete ruleset (requires jq and curl, your Zone ID and an API key (the one you used for you app is fine)):

1. Get ruleset:

curl --request GET   --url https://api.cloudflare.com/client/v4/zones/[zone id]/rulesets   --header 'Content-Type: application/json'   --header "Authorization: Bearer [API key]" | jq .

Look for the id of your app description “Ruleset for Wildebeest”
2. Delete ruleset:

root@k3s-sd-01:~# curl --request DELETE   --url https://api.cloudflare.com/client/v4/zones/[zone id]/rulesets/[ruleset id]   --header 'Content-Type: application/json'   --header "Authorization: Bearer [API key]"

from wildebeest.

ruleset are a bit in a weird state because the UI in the dashboard hasn't shipped yet so only way is to use the API.

from wildebeest.

We will work on the tutorial and clarify the required subscriptions and associated costs.

from wildebeest.

This has been the most time-consuming, convoluted "zero config" deployment I've ever attempted...but if you stick with it, eventually it works.

Now, to figure out how to log into this thing...

from wildebeest.

Thanks @xmflsct, that did the trick.

from wildebeest.

Also had the same issue. Got a Workers paid tier going and activated Durable Objects. Now getting slightly different error under download terraform state heading. I'd be expecting to see the account id where the "***" is being displayed below, so the process might be dropping that variable along the way possibly?

[ERROR] Failed to fetch
https://api.cloudflare.com/client/v4/accounts/***/storage/kv/namespaces/890796349881474ca919f40a73588fbd/values/terraform.tfstate - 404: Not Found);

from wildebeest.

@koehn: I ran into this issue earlier

29
In order to use Durable Objects, you must agree to pricing at https://dash.cloudflare.com/***/workers/overview?enable-durable-objects [code: 10084]

The fix is to replace the *** with your CF account number, drop that into your browser URL bar, and you'll be prompted to agree. IOW:
https://dash.cloudflare.com/<YOUR_CLOUDFLARE_ACCOUNT_NUMBER_GOES_HERE>/workers/overview?enable-durable-objects

from wildebeest.

I encountered simillar situation. I tried deployment but GitHub Action failed due to payment approval. Then I approved payment and re-run action to fail.

Situation is getting better when I removed all of related KV. Currently I got error:

│ Error: error creating Access Application for account "***": access.api.error.application_already_exists (11010)
│ 
│   with cloudflare_access_application.wildebeest_access,
│   on main.tf line 165, in resource "cloudflare_access_application" "wildebeest_access":
│  165: resource "cloudflare_access_application" "wildebeest_access" {
│ 
╵
╷
│ Error: failed to create ruleset "http_request_firewall_managed" as a similar configuration with rules already exists and overwriting will have unintended consequences. If you are migrating from the Dashboard, you will need to first remove the existing rules otherwise you can remove the existing phase yourself using the API (https://api.cloudflare.com/#zone-rulesets-delete-zone-ruleset).
│ 
│   with cloudflare_ruleset.wildebeest_inbox,
│   on main.tf line 174, in resource "cloudflare_ruleset" "wildebeest_inbox":
│  174: resource "cloudflare_ruleset" "wildebeest_inbox" {
│ 
╵

What should I do?

The workaround for the first error:

1. From your main dashboard, click on Zero Trust to open a new tab with the Zero Trust Dashboard
2. From there, (see image) select Applications, then click "Delete" on the wildebeest-XXXX entry

For the second error, see @koehn's response ^^ but also see my earlier response to him regarding deleting the KV Namespaces, DNS Records, Pages Projects, etc.

Once you do that, re-run the failed GH Actions job and cross your fingers

from wildebeest.

Thanks for trying @DataDrivenMD. It helps us improve the documentation and deployement process.

from wildebeest.

@DataDrivenMD Everything worked well. Thank you very much for great application! I'll create account.

from wildebeest.

Thanks @xmflsct, that did the trick.

Just seeing this message now, great to see that you found a fix @PrimeSitesCo

from wildebeest.

I've spent tons of time trying to deploy, and failing over and over again. I first deployed without agreeing to use DO, because it wasn't at all clear from the instructions here that I needed to do that in advance. But now, I've started paying $5/m to Cloudflare workers, which I think means DO should be enabled (the ?enable-durable-objects link doesn't do anything special for me - and I am correctly changing it to have my account ID). I also tried deleting the D1 database before a new deploy, didn't work. Couldn't figure out any other things I should delete to try and make this work.

Total Upload: 1.13 KiB / gzip: 0.49 KiB

✘ [ERROR] A request to the Cloudflare API (/accounts/***/workers/scripts/wildebeest-do) failed.

  In order to use Durable Objects, you must agree to pricing at https://dash.cloudflare.com/***/workers/overview?enable-durable-objects [code: 10084]
  
  If you think this is a bug, please open an issue at: https://github.com/cloudflare/workers-sdk/issues/new/choose

from wildebeest.

from wildebeest.

Thank you for the information. Unfortunately after I upgraded to a paid workers account, I ended up with the exact same error.

I agree the Readme is deceptive in cost.

from wildebeest.

@PrimeSitesCo I added a fix, could you please sync your fork? It will trigger a deploy build.

from wildebeest.

Thanks @xtuc, sync'd from main, but it didn't trigger a deploy. Manually re-ran the job and got past that step, but failed again at the Configure step I'm afraid. Something I did wrong perhaps?

from wildebeest.

I keep getting the same error Error message: open terraform.tfstate: permission denied. I've tried deleting the repo and starting again but I get the same error

from wildebeest.

Okay, let me revert my fix. Sonds like it's something else.

Have you tried to delete your KV namespaces starting with wildebeest and rerun?

from wildebeest.

Have you tried to delete your KV namespaces starting with wildebeest and rerun?

Hi there - I've tried this, and it doesn't fix the problem. What I've been able to figure out thus far is that the default "Cloudflare Workers" API Token template lacks the permissions necessary to fully deploy the Terraform template. Unless I'm overlooking something obvious, I don't believe any of the repo documentation mentions the CF API token permissions necessary for deployment. It may help to start there.

from wildebeest.

During the latest attempt I was able to get as far as this error message (see image):
error creating ruleset Wildebeest: exceeded maximum number of zone rulesets for phase 'http_request_firewall_managed'

Of note, I have no rulesets on this account (0 across all zones), and the target zone is on the Pro plan.

By this point in the TF run the following items have already been configured: Images variants, metadata 2 KV namespaces, D1 instance, DO, Pages project, DNS record, and Zero Trust application.
cc @xtuc

from wildebeest.

We are working to rewrite the README to provide better documentation and troubleshooting.

@DataDrivenMD
You shouldn't use the default "Cloudflare Workers" API token template. There's a deploy button in the README that has a link to create an API token with the right permissions.
Here's the link with the right template: https://dash.cloudflare.com/profile/api-tokens?permissionGroupKeys=[{%22key%22:%22d1%22,%22type%22:%22edit%22},{%22key%22:%22page%22,%22type%22:%22edit%22},{%22key%22:%22images%22,%22type%22:%22edit%22},{%22key%22:%22access%22,%22type%22:%22edit%22},{%22key%22:%22workers_kv_storage%22,%22type%22:%22edit%22},{%22key%22:%22access_acct%22,%22type%22:%22read%22},{%22key%22:%22dns%22,%22type%22:%22edit%22},{%22key%22:%22workers_scripts%22,%22type%22:%22edit%22},{%22key%22:%22account_rulesets%22,%22type%22:%22edit%22}]&name=Wildebeest

Once Terraform created some resources. I strongly recommend not deleting anything manually. Resolving the permission / error creating ruleset Wildebeest is enough to unblock the deployement.

I asked internally about your error creating ruleset Wildebeest error.

from wildebeest.

I re-synced and opted in to the pay-as-you-go plan and when I re-run the job I am still getting the same message:

✘ [ERROR] A request to the Cloudflare API (/accounts/***/workers/scripts/wildebeest-do) failed.
[28](https://github.com/koehn/wildebeest/actions/runs/4136772123/jobs/7151559387#step:19:29)

[29](https://github.com/koehn/wildebeest/actions/runs/4136772123/jobs/7151559387#step:19:30)
  In order to use Durable Objects, you must agree to pricing at https://dash.cloudflare.com/***/workers/overview?enable-durable-objects [code: 10084]

The latter link (dash.cloudflare.com...) is broken.

from wildebeest.

@DataDrivenMD You shouldn't use the default "Cloudflare Workers" API token template. There's a deploy button in the README that has a link to create an API token with the right permissions.

The magic link didn't work for me initially, which is why I ended up using the Workers Template. I wiped everything, disabled my browser's 3rd-party cookie blocker, then attempted Deploy to Cloudflare Workers button again-- that solved the API key issue.

Once Terraform created some resources. I strongly recommend not deleting anything manually. Resolving the permission / error creating ruleset Wildebeest is enough to unblock the deployement.

Yeah, I'm not touching anything once it is created unless I'm removing all resources before starting over from scratch.

I asked internally about your error creating ruleset Wildebeest error.

FWIW/FYI @xtuc: one of my earliest attempts didn't encounter this error at all, and successfully produced a managed ruleset. I deleted that ruleset between attempts. Could it be that the now-deleted rulesets are still being counted against my account? If so, then I suspect others will eventually hit this roadblock, too.

from wildebeest.

@xmflsct I can confirm that I am on the new managed rule interface

from wildebeest.

@DataDrivenMD sorry deleted my previous message. Digged a bit more, you should have deployed managed rules already in that target zone. If that is the case, for now a workaround is to remove Terraform's config of managing WAF like this commit.

from wildebeest.

@DataDrivenMD sorry deleted my previous message. Digged a bit more, you should have deployed managed rules already in that target zone. If that is the case, for now a workaround is to remove Terraform's config of managing WAF like this commit.

@xmflsct I don't have any deployed rules (at all). I'm happy to deploy the managed rules, but I believe that TF directive yields an exception to the managed rulesets. So, unless I'm misunderstanding the TF directive, the workaround would remove the bypass and thereby block ingress traffic to the /inbox endpoints.

from wildebeest.

OK, just made sure my repo was sync’ed, enabled DO, Enabled Access, and now this error in the “Download Terraform State” task:

✘ [ERROR] Failed to fetch https://api.cloudflare.com/client/v4/accounts/***/storage/kv/namespaces/[redacted]/values/terraform.tfstate - 404: Not Found);

from wildebeest.

OK, just made sure my repo was sync’ed, enabled DO, Enabled Access, and now this error in the “Download Terraform State” task:

✘ [ERROR] Failed to fetch https://api.cloudflare.com/client/v4/accounts/***/storage/kv/namespaces/[redacted]/values/terraform.tfstate - 404: Not Found);

@koehn Encountered this one, too. It happens because there's no continue-on-error: true directive in the GH Actions deploy.yml for that run command. The workaround is to follow the Starting Over instructions. You may be able to get away without deleting the fork, but you definitely need to go through the steps to delete any KV Namespaces, DO objects, DNS records, and Zero Trust/Access Applications that were added by the Terraform config. Once you do that, hit re-run on the failed GH Actions job and cross your fingers.

from wildebeest.

I encountered simillar situation. I tried deployment but GitHub Action failed due to payment approval. Then I approved payment and re-run action to fail.

Situation is getting better when I removed all of related KV. Currently I got error:

│ Error: error creating Access Application for account "***": access.api.error.application_already_exists (11010)
│ 
│   with cloudflare_access_application.wildebeest_access,
│   on main.tf line 165, in resource "cloudflare_access_application" "wildebeest_access":
│  165: resource "cloudflare_access_application" "wildebeest_access" {
│ 
╵
╷
│ Error: failed to create ruleset "http_request_firewall_managed" as a similar configuration with rules already exists and overwriting will have unintended consequences. If you are migrating from the Dashboard, you will need to first remove the existing rules otherwise you can remove the existing phase yourself using the API (https://api.cloudflare.com/#zone-rulesets-delete-zone-ruleset).
│ 
│   with cloudflare_ruleset.wildebeest_inbox,
│   on main.tf line 174, in resource "cloudflare_ruleset" "wildebeest_inbox":
│  174: resource "cloudflare_ruleset" "wildebeest_inbox" {
│ 
╵

What should I do?

from wildebeest.

@koehn: I ran into this issue earlier

29
In order to use Durable Objects, you must agree to pricing at https://dash.cloudflare.com/***/workers/overview?enable-durable-objects [code: 10084]

The fix is to replace the *** with your CF account number, drop that into your browser URL bar, and you'll be prompted to agree. IOW: https://dash.cloudflare.com/<YOUR_CLOUDFLARE_ACCOUNT_NUMBER_GOES_HERE>/workers/overview?enable-durable-objects

Just did this, thank you. New error:

So... I did this Visit the Access dashboard at https://dash.cloudflare.com/ and click the 'Enable Access' button. and there is no such button.

from wildebeest.

@DataDrivenMD sorry deleted my previous message. Digged a bit more, you should have deployed managed rules already in that target zone. If that is the case, for now a workaround is to remove Terraform's config of managing WAF like this commit.

@xmflsct I don't have any deployed rules (at all). I'm happy to deploy the managed rules, but I believe that TF directive yields an exception to the managed rulesets. So, unless I'm misunderstanding the TF directive, the workaround would remove the bypass and thereby block ingress traffic to the /inbox endpoints.

That is likely you have deployed rules in the past through the dashboard UI, hence an entrypoint ruleset had been automatically created by the UI behind the scene. Tested that you need to call the API https://developers.cloudflare.com/api/operations/zone-rulesets-delete-a-zone-ruleset to delete that entrypoint ruleset, then it can be managed by Terraform.

from wildebeest.

@yawnbox

So... I did this Visit the Access dashboard at https://dash.cloudflare.com/ and click the 'Enable Access' button. and there is no such button.

It's been re-branded as "Zero Trust" (see image):

from wildebeest.

@yawnbox

So... I did this Visit the Access dashboard at https://dash.cloudflare.com/ and click the 'Enable Access' button. and there is no such button.

It's been re-branded as "Zero Trust" (see image):

Thanks (again).

I walked through the pointless setting up of a free Zero Trust thing in which it charged my credit card $0. Re-ran the deploy, new error.

from wildebeest.

I walked through the pointless setting up of a free Zero Trust thing in which it charged my credit card $0. Re-ran the deploy, new error.

That means you forgot to delete the KV Namespaces from an earlier failed run. See my earlier comment for the workaround.

from wildebeest.

Thanks for trying @DataDrivenMD. It helps us improve the documentation and deployement process.

Thanks for being so responsive- that's what kept me going tbh. This is a great project, and happy to help smooth out the wrinkles.

from wildebeest.

I walked through the pointless setting up of a free Zero Trust thing in which it charged my credit card $0. Re-ran the deploy, new error.

That means you forgot to delete the KV Namespaces from an earlier failed run. See my earlier comment for the workaround.

Thank you. I am new to CF, I don't know what that means, so for anyone reading this, it's under Workers:

I needed to delete things in Overview, KV, and D1.

Yet again ran into another error after a new re-deploy, looks like the same one other folks have been getting.

│ Error: failed to create ruleset "http_request_firewall_managed" as a similar configuration with rules already exists and overwriting will have unintended consequences. If you are migrating from the Dashboard, you will need to first remove the existing rules otherwise you can remove the existing phase yourself using the API (https://api.cloudflare.com/#zone-rulesets-delete-zone-ruleset).
[320](https://github.com/yawnbox/wildebeest/actions/runs/4137852844/jobs/7153536228#step:21:321)
│ 
[321](https://github.com/yawnbox/wildebeest/actions/runs/4137852844/jobs/7153536228#step:21:322)
│   with cloudflare_ruleset.wildebeest_inbox,
[322](https://github.com/yawnbox/wildebeest/actions/runs/4137852844/jobs/7153536228#step:21:323)
│   on main.tf line 174, in resource "cloudflare_ruleset" "wildebeest_inbox":
[323](https://github.com/yawnbox/wildebeest/actions/runs/4137852844/jobs/7153536228#step:21:324)
│  174: resource "cloudflare_ruleset" "wildebeest_inbox" {
[324](https://github.com/yawnbox/wildebeest/actions/runs/4137852844/jobs/7153536228#step:21:325)
│ 
[325](https://github.com/yawnbox/wildebeest/actions/runs/4137852844/jobs/7153536228#step:21:326)
╵
[326](https://github.com/yawnbox/wildebeest/actions/runs/4137852844/jobs/7153536228#step:21:327)
Error: Terraform exited with code 1.
[327](https://github.com/yawnbox/wildebeest/actions/runs/4137852844/jobs/7153536228#step:21:328)
Error: Process completed with exit code 1.

Re-ran the deploy, it failed again. Went back to the dashboard and deleted everything, again. This time there was a DNS record for the domain, deleted it too.

and... it failed again.

│ Error: error creating cloudflare pages project "wildebeest-yawnbox": A project with this name already exists. Choose a different project name. (8000002)
[315](https://github.com/yawnbox/wildebeest/actions/runs/4137953565/jobs/7153766940#step:21:316)
│ 
[316](https://github.com/yawnbox/wildebeest/actions/runs/4137953565/jobs/7153766940#step:21:317)
│   with cloudflare_pages_project.wildebeest_pages_project,
[317](https://github.com/yawnbox/wildebeest/actions/runs/4137953565/jobs/7153766940#step:21:318)
│   on main.tf line 101, in resource "cloudflare_pages_project" "wildebeest_pages_project":
[318](https://github.com/yawnbox/wildebeest/actions/runs/4137953565/jobs/7153766940#step:21:319)
│  101: resource "cloudflare_pages_project" "wildebeest_pages_project" {
[319](https://github.com/yawnbox/wildebeest/actions/runs/4137953565/jobs/7153766940#step:21:320)
│ 
[320](https://github.com/yawnbox/wildebeest/actions/runs/4137953565/jobs/7153766940#step:21:321)
╵
[321](https://github.com/yawnbox/wildebeest/actions/runs/4137953565/jobs/7153766940#step:21:322)
╷
[322](https://github.com/yawnbox/wildebeest/actions/runs/4137953565/jobs/7153766940#step:21:323)
│ Error: failed to create ruleset "http_request_firewall_managed" as a similar configuration with rules already exists and overwriting will have unintended consequences. If you are migrating from the Dashboard, you will need to first remove the existing rules otherwise you can remove the existing phase yourself using the API (https://api.cloudflare.com/#zone-rulesets-delete-zone-ruleset).
[323](https://github.com/yawnbox/wildebeest/actions/runs/4137953565/jobs/7153766940#step:21:324)
│ 
[324](https://github.com/yawnbox/wildebeest/actions/runs/4137953565/jobs/7153766940#step:21:325)
│   with cloudflare_ruleset.wildebeest_inbox,
[325](https://github.com/yawnbox/wildebeest/actions/runs/4137953565/jobs/7153766940#step:21:326)
│   on main.tf line 174, in resource "cloudflare_ruleset" "wildebeest_inbox":
[326](https://github.com/yawnbox/wildebeest/actions/runs/4137953565/jobs/7153766940#step:21:327)
│  174: resource "cloudflare_ruleset" "wildebeest_inbox" {
[327](https://github.com/yawnbox/wildebeest/actions/runs/4137953565/jobs/7153766940#step:21:328)
│ 
[328](https://github.com/yawnbox/wildebeest/actions/runs/4137953565/jobs/7153766940#step:21:329)
╵
[329](https://github.com/yawnbox/wildebeest/actions/runs/4137953565/jobs/7153766940#step:21:330)
Error: Terraform exited with code 1.
[330](https://github.com/yawnbox/wildebeest/actions/runs/4137953565/jobs/7153766940#step:21:331)
Error: Process completed with exit code 1.

from wildebeest.

^^ The workaround for that last error is here: #227 (comment)

from wildebeest.

Thanks, @DataDrivenMD. Made it to a successful deployment in the end following the Starting Over guide. Opened the Mastodon app on a mobile and managed to get through to the login interface of my new Wildebeest instance, but when I hit the register button I got a "Worker exceeded resource limit" error.
After trying that a few times in a row it went through. Publishing a post seems problematic though. I get the below type of errors when looking at the wildebeest-do service under Workers. Also, the app seems to be offline with searching etc. not working.

Signing out of the Mastodon app and back in, now shows that it requires authorisation, which is the step that gives that Worker exceeded resource limit error.

from wildebeest.

@PrimeSitesCo can you please double check that Worker is set to unboud in Pages? If not, it requires a deployement to apply.

from wildebeest.

@xtuc accessing either of the wildebeest-consumer-xxxxx and wildebeest-do workers show the little Unbound icon top-right.

Is that all I need to be looking out for?

from wildebeest.

@PrimeSitesCo yes. The Worker exceeded resource limit happens during the registration because it generates your user's key pair and encrypt it to store in D1. Which might consume too much CPU or memory, but only required the first time you login in.

What client are you using? Official Mastodon app on iOS?

from wildebeest.

Yes, first used it with Mastodon, but also tried Tooot and got the same issue.

from wildebeest.

@PrimeSitesCo it is under Pages that you need to set functions to unbound, see https://github.com/cloudflare/wildebeest#error-1102

After changing the setting of Pages, you need to re-run the last GitHub deploy action to let the new settings apply

from wildebeest.

I apologize if this was already covered. I tried finding how to fix this, but I'm not seeing anything specific about this. I am running in to Node.js 12 actions are deprecated when I try to deploy. Do we know how to fix that?

from wildebeest.

^^ The workaround for that last error is here: #227 (comment)

this presumes a great deal. I do not use Cloudflare. I do not interact with it with CLI. This makes no sense. Am I hearing that for me to be able to deploy Wildebeest, I need to setup some other environment just to delete CF's mistakes?

from wildebeest.

^^ The workaround for that last error is here: #227 (comment)

this presumes a great deal. I do not use Cloudflare. I do not interact with it with CLI. This makes no sense. Am I hearing that for me to be able to deploy Wildebeest, I need to setup some other environment just to delete CF's mistakes?

I share your frustration. I don't work for CF, I'm just trying to help; I wish I could do more.

from wildebeest.

@yawnbox ruleset have been removed from the deployement because of the issues 9c570a5. However, you'll need to delete the ruleset manually from your account using the API, as we don't have a UI in the dashboard yet.

from wildebeest.

@yawnbox ruleset have been removed from the deployement because of the issues 9c570a5. However, you'll need to delete the ruleset manually from your account using the API, as we don't have a UI in the dashboard yet.

Thanks, I'm just deleting my paid services from CF. This isn't turn key and is arguably harder to manage versus deploying Mastodon in a VM.

from wildebeest.

@yawnbox thanks for trying, we are improving the deployment process and documentations. I'll go ahead and close the issue for now.

from wildebeest.

I tried deploying just this morning (Feb 19) and I am still getting "Node.js 12 actions are deprecated. Please update the following actions to use Node.js 16: actions/checkout@v2.". I tried "Sync Fork" and I am not behind the upstream branch.

from wildebeest.

Node.js 12 actions are deprecated. Please update the following actions to use Node.js 16: actions/checkout@v2 is just a warning, it doesn't cause the deployement to fail.

I see in your logs:

✘ [ERROR] A request to the Cloudflare API (/accounts/***/workers/scripts/wildebeest-do) failed.

  In order to use Durable Objects, you must agree to pricing at https://dash.cloudflare.com/***/workers/overview?enable-durable-objects [code: 10084]
  
  If you think this is a bug, please open an issue at: https://github.com/cloudflare/workers-sdk/issues/new/choose

Please agree with the pricing and retry.

from wildebeest.

OK, turns out that paying for Cloudflare Workers did not actually enable DO. I managed to get link to work and bring up modal asking to agree to DO (which didn't come up before, even using that link). Got past DO part of deployment. Now failing here:

│ Error: failed to create DNS record: Authentication error (10000)

Going to try delete DNS records then attempt deploy again.

from wildebeest.

OK, turns out that paying for Cloudflare Workers did not actually enable DO. I managed to get link to work and bring up modal asking to agree to DO (which didn't come up before, even using that link). Got past DO part of deployment. Now failing here:

│ Error: failed to create DNS record: Authentication error (10000)

Going to try delete DNS records then attempt deploy again.

Like you, I'm now paying for Cloudflare Workers, but don't appear to have DO enabled. How did you fix this?

The link in the error message doesn't work for me - I just get a 404.

from wildebeest.

@maxtappenden are you putting your Cloudflare user ID in the URL in place of ***?

from wildebeest.

@maxtappenden are you putting your Cloudflare user ID in the URL in place of ***?

No! 😳 Didn't notice it. I only looked at the domain and the query string 😁

Thank you!

from wildebeest.

Regarding getting past the durable object error you gotta go here and scroll to the bottom of the page and click enable durable object (make sure the replace the account id and worker name.

https://dash.cloudflare.com/accountId/workers/services/view/myWorker/production

from wildebeest.