You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 3, 2023. It is now read-only.
I propose a new per-environment, non-inherited key in wrangler.toml, called actors-beta.
This key will be a table with two properties. Actor namespaces have an id, similar to the id of a KV namespace.
uses: array of tables
binding - same meaning as kv_namespaces
Then the names XOR ids this binding uses
fields for the name variant
name - name of the actors namespace
preview_name - name of the actors namespace to be used in preview
fields for the id variant
id - id of the actors namespace
preview_id - name of the actors namespace to be used in preview
implements: array of names
name - name of the actors namespace
If a name is provided here, wrangler will prompt to create the namespace for the user.
I'm not sure if an id possibility makes sense here, as there is a chicken/egg problem.
It might be useful for silencing any warnings for a project with no routes or workers_dev = true,
which would be the case for a project which only implements an actor.
Errors should be thrown if a namespace id or name in uses does not exist.
Supporting only IDs in bindings saves us an API request on deploy, but composes weirdly with the implements field which only makes sense for name.
All possible deployment scenarios supported by the runtime/platform, such as a worker implementing an actor namespace and having a route, should be supported by wrangler, but handling dependency loops when a script both uses and implements the same actor namespace is not in scope. However, we should warn in these scenarios, as there is a possibility for eyeball errors if not handled carefully by the user.
I chose to add a new key specific to actors, rather than a new project type, or a generic invocation_type field, to potentially support other invocation types in the future that may coexist in the same project.
Other considerations:
The actors api has new token scopes, so wrangler login will need to be done again.
Wrangler’s DeployConfig type does not support uploading scripts with no route. This used to not make sense, but it does now if you have a script which only purpose is to implement an actor namespace.
Wrangler's DeployConfig type has a semantic restriction that environments can only deploy to two invocation types (zoned or zoneless). It makes a lot of sense to have a single environment that both implements an actor namespace, and is invokable from workers.dev or a zoned route.
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had recent activity in the last 180 days. It will be closed if no further activity occurs in the next week. Please feel free to comment if you'd like it to remain open, and thank you for your contributions.
I propose a new per-environment, non-inherited key in wrangler.toml, called
actors-beta
.This key will be a table with two properties. Actor namespaces have an
id
, similar to the id of a KV namespace.uses
: array of tablesbinding
- same meaning as kv_namespacesname
- name of the actors namespacepreview_name
- name of the actors namespace to be used in previewid
- id of the actors namespacepreview_id
- name of the actors namespace to be used in previewimplements
: array of namesname
- name of the actors namespaceIt might be useful for silencing any warnings for a project with no routes or workers_dev = true,
which would be the case for a project which only implements an actor.
Errors should be thrown if a namespace id or name in
uses
does not exist.Supporting only IDs in bindings saves us an API request on deploy, but composes weirdly with the
implements
field which only makes sense forname
.All possible deployment scenarios supported by the runtime/platform, such as a worker implementing an actor namespace and having a route, should be supported by wrangler, but handling dependency loops when a script both uses and implements the same actor namespace is not in scope. However, we should warn in these scenarios, as there is a possibility for eyeball errors if not handled carefully by the user.
I chose to add a new key specific to actors, rather than a new project type, or a generic invocation_type field, to potentially support other invocation types in the future that may coexist in the same project.
Other considerations:
The actors api has new token scopes, so wrangler login will need to be done again.
Wrangler’s DeployConfig type does not support uploading scripts with no route. This used to not make sense, but it does now if you have a script which only purpose is to implement an actor namespace.
Wrangler's DeployConfig type has a semantic restriction that environments can only deploy to two invocation types (zoned or zoneless). It makes a lot of sense to have a single environment that both implements an actor namespace, and is invokable from workers.dev or a zoned route.
The text was updated successfully, but these errors were encountered: