workers-sdk
workers-sdk copied to clipboard
cloudflare
🐛 BUG: pages tail failing
Which Cloudflare product(s) does this pertain to?
Pages
What version(s) of the tool(s) are you using?
3.51.2 [Wrangler]
What version of Node are you using?
v18.19.0
What operating system and version are you using?
Mac Sonoma
Describe the Bug
▶ wrangler pages deployment tail --project-name website --environment production
⛅️ wrangler 3.51.2 (update available 3.52.0)
-------------------------------------------------------
No deployment specified. Using latest deployment for production environment.
✘ [ERROR] A request to the Cloudflare API (/accounts/950816f3f59b079880a1ae33fb0ec320/pages/projects/website/deployments/dd61cf7e-6839-4ca2-a836-13e1d8daee01/tails) failed.
workers.api.error.unknown [code: 8000068]
If you think this is a bug, please open an issue at:
https://github.com/cloudflare/workers-sdk/issues/new/choose
Please provide a link to a minimal reproduction
No response
Please provide any relevant error logs
No response
@richburdon can you reproduce this across multiple projects/deployments, or is it specific to one?
I can reproduce this on my project, it's deploying and all looks good but nothing to see. When I try to view logs I get the exact error log above. ⛅️ wrangler 3.53.1
@richburdon can you reproduce this across multiple projects/deployments, or is it specific to one?
@penalosa same thing across all projects.
Same issue for Pages workers since wrangler pages deployment list just returns a list of abbreviated IDs. So you're forced to go to the CF admin panels and hunt down the deployment ID every time. And as far as I can tell the only play to get the ID is from the URL of the deployment.
Would be great if there were --filter and --json options for wrangler that returned the full deployment IDs so we could build more automated ways of using wrangler in our development and testing workflows.
Also, at least wrangler pages deploy could return (ideally with --json) the deployment ID :).
I tried writing a script to parse the output, but the borders around the data make that very difficult.
E.g.,
#!/bin/sh
DEPLOYMENT=$(wrangler pages deployment list | grep -m 1 -o 'hub-profile/.*')
echo "Tailing deployment: $DEPLOYMENT"
IFS='/' read -r PROJECT DEPLOYMENT_ID <<< "$DEPLOYMENT"
wrangler pages deployment tail --project-name=$PROJECT $DEPLOYMENT_ID
hi @richburdon :) we've tried reproducing the issue and it's inconsistent across various projects -- some return the same error, and some are fine, so it looks like this is an issue with the API. we've created an internal ticket (WC-2965) and notified the relevant team. there's also an existing internal issue (WC-2399) to improve error messaging such that these kinds of errors become more actionable. we've added this issue as another example on that ticket. cc @korinne
regarding your note about deployment ids, it sounds like this is a feature request, but just to confirm, are you running into any issues when getting deployment ids?
Same issue here. I have two Pages workers - both fail when I try to tail.
The requested Worker version could not be found, please check the ID being passed and try again.
[code: 8000068]
Same thing happens when I try to tail from dashboard.
hi @richburdon :) per our comment above, this seems to be an API issue, which we're tracking internally. as such, we're going to close this issue, but if you have a bug or feature request with getting deployment ids, please feel free to open a new issue.
@alex35mil it looks like your error message is slightly different from the one @richburdon was getting. can you please open a separate issue and include a repro? thank you!
Was this issue resolved? I'm still seeing this even though this has been marked as closed. Also afaik @alex35mil 's and @richburdon 's issues' error ids are the exact same, so I don't know why it was said to have a different error message.
I'm having the same issue. Is there any way to see tail the logs for pages with this unresolved?
I'm still getting this.
It seems very random. Sometimes it works fine. Other times now. Very hit and miss.
@lrapoport-cf - can you please re-open this.
I'm using wrangler 4.15.2 and still getting this error.
hi @magick93 :) previously it was determined this is an API issue (internal ticket WC-2965), so the issue was closed as there isn't anything we can do within wrangler. if you're running into something new, can you open a new issue and include a link to a repro so we can investigate?
@lrapoport-cf - closing this sends the wrong message. Especially when it marked as "closed this as completed on Jan 7, 2025". It says to the many people that it is either (a) believed to be fixed or (b) we are not interested in received anymore people telling us they also have this problem.
Also, to say its not a wrangler problem because it is a problem with a dependency doesnt make much sense. The fact of the matter is a wrangler function isnt functioning correctly.
This, or at least another github issue, should at the very least, serve as a placeholder to reflect the status and gather feedback from effected users. It also shows how long this issue has gone unresolved.
hi @magick93 and all, really appreciate your feedback. community engagement enables us to support you all best.
to give a little context, this issue was originally determined to be at the API layer, and thus requiring a fix there. as a small team, we generally try to limit items in the workers-sdk backlog to those that our team can action on, so as a result we had closed the issue.
however, we appreciate that there are still several people running into this, and we have a commitment to support our users. as such, while changes may not be needed within workers-sdk, we are re-opening the issue to keep communications open and track progress. we have also synced with the relevant internal team and they are prioritizing investigation on the API side (cc @korinne ).
thanks again for your follow-up!
Hey folks, attempting to reproduce this! Wanted to 1) confirm this is still an active issue in Wrangler 4.X, and 2) clarify what steps (and/or if we had a repo that replicated this behavior) were taken to get this error.
I've tried to reproduce with a few projects by doing a simple deployment out of the pages fixtures directory (pages-functions-app) using Wrangler 4.20.0:
- wrangler pages deploy public --branch production --project-name website
- wrangler pages deployment tail --project-name website --environment production
I'm not able to replicate this error, but would love more ideas on how to reproduce.
Hi @WillTaylorDev
Its very hard to reproduce. The most recent version that I experienced this issue is wrangler 4.15.2.
From memory this would correlate with build failures. I could run npx wrangler pages deployment tail --project-name <project_name> successfully most of the time. But when there had been a few builds that failed, then it would stop working. It was almost as if the cf backend couldnt find the active deployment.
I was initially thinking maybe this was related to the number of deployment (eg. the production deplayment wasn't in the first page of results), but not able to replicate that way either. Makes more sense that it's related to a build failure in some way.
If/when this occurs again for you, could you (or anyone experiencing this!) share a deployment ID? I'll be able to discover more that way.
Bug found; if there are builds which haven't been completed yet, we can't tail them. Wrangler does not filter out in-progress builds, causing this error (and also why it was so hard to reproduce) if the most recent build hasn't yet completed.
Fix here: https://github.com/cloudflare/workers-sdk/pull/9684