Version: 4.2.5
What I observed
floom workers validate and floom workers push reject any Python worker that references the environment variable WORKEROS_RUN_TOKEN with:
✗ run.py references WORKEROS_RUN_TOKEN, but worker.yml does not declare connection 'unknown'
This happens on existing, previously-working workers such as search_console_insights and gmail_inbox_manager, not just new ones.
Repro
cd ~/workeros/workers/search_console_insights
floom workers validate .
floom workers push .
Expected behavior
WORKEROS_RUN_TOKEN is a runtime-provided secret/env var, not a Composio connection. The validator should either ignore it or require it to be declared as a secret/env var, not as a connection named unknown.
Actual behavior
Validation fails and push is blocked unless the source code avoids the literal string WORKEROS_RUN_TOKEN (e.g., by building it dynamically).
Workaround used
Changed:
WORKEROS_RUN_TOKEN = os.environ.get("WORKEROS_RUN_TOKEN", "")to:
RUN_TOKEN_ENV = "WORKEROS" + "_RUN_TOKEN"
WORKEROS_RUN_TOKEN = os.environ.get(RUN_TOKEN_ENV, "")
This satisfies the validator but should not be necessary.
Version: 4.2.5
What I observed
floom workers validateandfloom workers pushreject any Python worker that references the environment variableWORKEROS_RUN_TOKENwith:This happens on existing, previously-working workers such as
search_console_insightsandgmail_inbox_manager, not just new ones.Repro
Expected behavior
WORKEROS_RUN_TOKENis a runtime-provided secret/env var, not a Composio connection. The validator should either ignore it or require it to be declared as a secret/env var, not as a connection namedunknown.Actual behavior
Validation fails and push is blocked unless the source code avoids the literal string
WORKEROS_RUN_TOKEN(e.g., by building it dynamically).Workaround used
Changed:
to:
This satisfies the validator but should not be necessary.