If i create a user script and delete it after 5 minutes does that incur the full 0.02 charge?
If i create a user script and delete it after 5 minutes does that incur the full 0.02 charge?
DGood question :monkaHmm:
RIs this the best practices then? One KV namespace per user
WDepends on the use case but if you're just providing these to users then yes definitely
WIf this was a namespace where you control the reads then one namespace overall is ok
RYes it's for users. That's why I was hoping that's the route but ok thank you
KI'm hoping for it be pro rated hourly or something similar 
WI haven't tried the JS SDK for this yet, let me take a quick look at the code and see if I can figure out what it's doing
DWhat's the best way to develop locally for WFP with Wrangler? :monkaThink:
WIt seems like it should be uploading a
multipart/form-data
Mdocs are incoming, but as of right now there's a prerelease Wrangler branch
wrangler@dispatch-namespaces-devyup!
--remote
RYes my next question was how we should test users workers before deploying
WMy recommendation for user Worker logs is enable logpush and send them to Baselime
Wor you can attach a Tail Worker and send them anywhere/manage them as you want 
Mhere's some docs for local development https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/get-started/developing-with-wrangler/
this wrangler prerelease branch is experimental, but we're looking to solidify this and get it in soon
this wrangler prerelease branch is experimental, but we're looking to solidify this and get it in soon
Cloudflare Docs
To test your Dispatch Worker, user Worker and Outbound Worker before deploying to production, you can use Wrangler for development and testing.
RThanks .. next I'm looking for a good API or to build one for esbuild so I can build customer workers w imports etc.
NCheck out https://esb.denoflare.dev
Roh wow ! Is this reliable ?
Nin my experience it is ... it's run by @John Spurlock
RTy
BSeems like old scripts cant be deleted with error
I tried deleting one which was uploaded a few months ago but it fails, however when I tried (the same way) deleting one that was uploaded this week it worked fine. I tried with the force flag too.
workers.api.error.unknownI tried deleting one which was uploaded a few months ago but it fails, however when I tried (the same way) deleting one that was uploaded this week it worked fine. I tried with the force flag too.
UAre you on enterprise or did you get it on pay-go before the plan released? Either way sending an account id can probably help an employee look at it when they see it
BEnterprise & access through tanushree. I was able to resolve it by uploading a new script with the same name then deleting it.
Rwheres the link for buying WfP ? or upgrading from paid workers to that
AClick it in navigation on the dashboard and then the button to sign up..
Ryah im not seeing it on my other account hm
BI don't see the option to delete secrets in Workers for Platforms API docs. How do you delete secrets using the API?
BThis should work
BWell it's meant to work but it has an
workers.api.error.unknownThanks. Yes, I tried this before; I got the same error. Another issue I noticed is I can't access the "cf" request object in user workers.
Rreally? So their workers don't image access to the cf request object from the context ?
RIs that by design
BYeah the API seems to have a few issues unfortunately.
As for the cf props, something similar happens on DOs too - see the explanation of why here: durable-objects
If your project doesn't have a strict requirement of using the "fetch" entry point you might be able to use RPC to pass it down to the user worker (I've not tested this though)
As for the cf props, something similar happens on DOs too - see the explanation of why here: durable-objects
If your project doesn't have a strict requirement of using the "fetch" entry point you might be able to use RPC to pass it down to the user worker (I've not tested this though)
BI will check this. I have passed "cf" fields as request headers - as a quick fix.
BThere's a workaround I just figured out for deleting secrets, you can use the 'Patch Script Settings' API with a new array of bindings and it'll replace all the existing bindings with the ones specified. If you have other secrets you'd have to define them again which is a bit annoying
