Skip to content

All 9 scheduled flows declare no config.organization — the hosted runtime (framework past objectstack ecdfc9411) already refuses to bind them, and it blocks the next hosted production release #1969

Description

@hotlong

Filing-gate: ① product defect with reach measured (a marketplace install of v3.1.0 on the hosted pre-production runtime), filed on the maintainer's direction

Maintainer direction, 2026-09-28, session session_d8bf7d34-4f31-407d-ac85-6cb849eec4bf: the next hosted production release is paused until this and objectstack-ai/cloud#2471 are resolved (verbatim choice: 「暂停发版,开卡派人查(推荐)」).

Measured

The hosted runtime pins the framework by commit, not by npm release, and its current pin already carries the scheduled-flow organization contract (objectstack ecdfc9411, the #17334 family). Installing HotCRM v3.1.0 from the marketplace into a fresh hosted environment logs, for every scheduled flow:

[schedule] NOT BOUND — scheduled flow '…' declares no acting organization: its start node's config is missing the organization key.

It is followed by Failed to bind flow '…' to trigger 'schedule' — the flow stays registered but will NOT fire.

The 9 flows: demo_bootstrap, case_sla_monitor, contract_renewal, opportunity_stagnation, campaign_completion, contract_expiration, forecast_snapshot, quote_expiration, task_due_reminder.

Why it blocks a release

The hosted production runtime still runs a framework pin from before that contract, so these flows bind there today. The next production release moves the pin, and then contract renewal, case SLA monitoring, quote/contract expiry, task reminders, forecast snapshots and campaign completion silently stop firing in every production tenant that has HotCRM installed. The only trace is the log lines above.

Ask

Declare the acting organization on each scheduled flow's start node, in a way that the published framework (17.4.0, which this repo pins) accepts and the hosted runtime's pin requires. Publish that version to the marketplace, and say how existing installs pick it up. #1892 (demo_bootstrap, on hold) names the same contract as arriving "in the next release". For hosted tenants it has already arrived, so this card cannot wait for the npm release.

Reader

The repo:hotcrm seat, from pm:queue. The consumer is objectstack-ai/cloud's production release, which is blocked on this card.

Dedupe

Search (open + closed) on 2026-09-28: schedule organization → 28 hits, NOT BOUND organization → 83, config.organization flow → 1. The only open topical hit is #1892, which concerns demo_bootstrap's cost and its boot claim, not the binding refusal across all 9 flows.

Activity

  1. added
    bugSomething isn't working
    backendServer-side behaviour — hooks, flows, actions
    pm:queueReady for the PM dispatch loop
    priority:p1High: required for production / M2
    on Sep 28, 2026
  2. hotlong commented on Sep 28, 2026

    @hotlong
    ContributorAuthor

    Premise falsified before dispatch: nothing lands in this repo. Closing not_planned; the carrier is objectstack-ai/cloud#2332

    Seat session_d8bf7d34-4f31-407d-ac85-6cb849eec4bf (the seat that filed this card), 2026-09-28T13:44Z. The maintainer asked for this card to be dispatched through the PM loop. The pre-dispatch premise check falsified the card's own ask, so a dev would have been sent to write the wrong fix.

    What this card asked: declare a literal acting organization on each of HotCRM's 9 scheduled flows.

    Why that is impossible here, and unnecessary:

    1. The contract's value is a concrete sys_organization.id (ScheduleOrganizationSchema: a non-empty string; "no fan-out … no fallback"). A marketplace package installed into arbitrary tenants cannot know that id at authoring time, so no HotCRM edit satisfies it.
    2. Upstream already settled package-authored scheduled work after the hosted pin bdea10a1. objectstack#18198 made it a deployment decision, off by default. objectstack#18420 means that under posture single the declaration is not read: trigger-schedule on objectstack main binds an undeclared flow "with NO acting organization — the run carries none and the deployment's single organization is resolved beneath each write". Only isolated refuses it.
    3. A hosted tenant kernel is single-organization. artifact-kernel-factory.ts enables multi-org only under OS_MULTI_ORG_ENABLED / OS_MULTI_TENANT, which the tenant runtime leaves unset. This is a code reading, to be proven at the pin move.
    4. The hosted pin move is in flight as objectstack-ai/cloud#2332 (PR objectstack-ai/cloud#2423, interim pin e4d3f2ca). That pin contains #18420's merge 0a56d3b511 (compare: ahead). Whether a hosted kernel runs scheduled work at all is the plan-keyed policy ruled on objectstack-ai/cloud#2337 (free ⇒ off, team and above ⇒ on).

    ⇒ The HotCRM flows bind again once the hosted pin passes #18420 and #2337's policy is wired, with no HotCRM change. The verification request moves to #2332 as a cross-seat comment. Reopen free of charge if the pin move proves otherwise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    backendServer-side behaviour — hooks, flows, actionsbugSomething isn't workingpriority:p1High: required for production / M2

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions