Legacy worker environment overwrite with wrangler2
# workers-help
t
Last year i created a worker that was published with 2 dash environments (staging and production) Recently i updated the code to use wrangler2 with publish command and what this did was generate a new worker in cloudflare based on the --env flag provided "wrangler publish --env production", this was not what i wanted (2 workers instead of 1, resulting in 3 workers where one is the older legacy that is bound to a durable object per legacy environment to make things worse). The problem is that i want to overwrite the old worker for each environment. (keeping the durable object binding intact per env) I managed to do this by specifying the name of each environment in the toml file but when i publish it only seems to update the code for the main environment that is currently set to staging. (resulting in not being able to update production env, only environment vars) Any ideas how i would overwrite the code for the production based on the --env environment, possibly by setting it up in the toml file ? -------- Old situation with one worker with 2 environments (production,staging): example-worker_staging example_worker_production New situation with two workers with 1 environment (production) example-worker-staging example-worker-production
j
Generally, you can't. The old dash service environments has been killed
You will probably want to migrate to wrangler environments, which results in 2 separate workers
t
How would that work with the durable object created on the old workers. I am able to create 2 new workers with wrangler and use the script name to bind it but i am worried if i remove the legacy worker that it will remove the durable object (and all its data, there seems no way to back it up i guess).
j
I am pretty sure that deleting the worker won't delete the Durable Objects, but I'm not 100% honestly
t
Its also a little bit tricky because the older worker created example_staging_OBJECTNAME where example is the worker name and staging is the dahs environment and OBJECTNAME is the durable object. It would be so much easier if we could just bind it via namespace id instead of script name since that is different in legacy vs wrangler. Currently trying to bind it using script name but its a puzzle, looks good with script name but it seems to auto bind it via toml to the staging environment again (since that is/was the main environment on the old worker)
i guess this would be the part i am interested in documentation on transfering / cloning the durable object with data. https://developers.cloudflare.com/workers/learning/using-durable-objects/#configuring-durable-object-classes-with-migrations