Federation install stores an imported flow ownerless, so no read path can ever see it; register-authored flows cannot be bundled

[rubenvdlinde]

Summary

Federation and the flow stores disagree, in two directions. Both were found live on a dev instance running development at 1.1.5-unstable.20260827012918, and both report success while doing nothing.

1. federated-config/install returns a uuid for a flow that does not exist

POST /api/federated-config/install  { type: openregister.flows, bundle, source: ConductionNL/flow-pack }
→ HTTP 200  {"installed":["af100293-801e-45b3-bed6-ab19ee2e27a8"]}

That uuid exists nowhere. Confirmed three independent ways:

GET  /api/flows?_limit=1000        → 72 flows, af100293… not among them
GET  /api/flows/af100293-…         → HTTP 404 {"error":"No such flow"}
POST /api/flow-runs/test {flowId}  → HTTP 404 {"error":"No such flow: af100293-…"}

It is not in the flows register either (2 objects, neither is it).

This is the worst shape a bug can take: the caller is handed an identifier, HTTP 200, and an installed array of length 1. Nothing about that response suggests the flow was not persisted. A consumer installing a flow pack gets a receipt for goods that were never delivered, and only discovers it when something tries to run the flow.

2. A flow authored in the flows register cannot be bundled

OpenRegister has two stores for "a flow":

store	written by	read by
openregister_flows table	POST /api/flows	FlowMapper, and so FlowShareableConfigType
objects in the flows register	POST /api/objects/{reg}/{sch}	the resolver

FlowShareableConfigType bundles via FlowMapper, so it reads only the first. Bundling a register-authored flow returns an empty set with HTTP 200:

POST /api/federated-config/bundle  {flowIds: ["628a655b-…"]}   (register-authored)
→ HTTP 200  {"type":"openregister.flows","version":"1.0","flows":[]}

Verified with a control — the same request for a table-backed flow returns 1:

POST /api/federated-config/bundle  {flowIds: ["7f9ea270-…"]}   (via /api/flows)
→ HTTP 200  {"flows":[{"name":"…","nodes":[…]}]}

This matters because the register is a documented place for a flow to live. lib/Settings/flow_register.json describes itself as "the store the resolver reads by default … so triggers, sub-flows and the /test endpoint all work with a flow authored here." A flow authored exactly as documented silently cannot be shared, and the empty bundle carries no hint that the store was the problem.

Why it went unnoticed

federated-config.spec.ts covers this path, but the whole file was dead: its beforeAll resolves a flows register that had never been seeded on the instance, so every test in the file errored before reaching an assertion. Once the register was imported (see #2903), the file ran and both defects surfaced within two assertions of each other.

Two further fixture problems had to be cleared first, both stale against the current flow grammar:

• makeFlow() hung type + config off an edge. The validator refuses that outright — "a node is the action that runs and an edge is sequence, so nothing reads this step" — so the flow was never created and the failure surfaced later as flows.length === 0, reading exactly like a broken bundler. Fixed by moving the step onto a node.
• The fixture then authored into the register, which is symptom 2 above. Pointed at /api/flows so the bundling test tests bundling.

Symptom 1 is what remains red after both fixture fixes, and it is a product defect, not a test one.

Suggested direction

Not prescribing the fix, but the shape of the question: either the two stores become one, or every federation path names which store it operates on and refuses — loudly — when handed an id from the other. What must not survive is an install that returns an id for nothing.

[github-actions]

Thank you for opening this issue! It has been assigned to @rubenvdlinde for review.

What happens next:

1. A maintainer will review this issue and determine the appropriate action
2. If accepted, it may be converted into an OpenSpec change for structured development
3. You will be notified of any status changes

Triage labels:

• triage:accept-feature — accepted as a new feature
• triage:accept-bugfix — accepted as a bug fix
• triage:needs-info — more information needed
• triage:wontfix — will not be addressed
• triage:duplicate — duplicate of another issue

[rubenvdlinde]

Correction — symptom 1's cause was wrong, and the real one is worse

I wrote above that the installed flow "exists nowhere". That is incorrect. The row is in oc_openregister_flows:

SELECT uuid, name, owner IS NULL AS ownerless, organisation IS NULL AS orgless, enabled
  FROM oc_openregister_flows WHERE uuid='af100293-801e-45b3-bed6-ab19ee2e27a8';

 af100293-… | e2e-ident-… schedule naming the caller | t | t | f

install inserted it correctly. What is wrong is that nothing can ever see it again.

The actual mechanism

FlowShareableConfigType::deserialise() deliberately stores an imported flow ownerless:

// An imported flow lands DISABLED and OWNERLESS, whatever the bundle said.
// `owner` and `organisation` are not portable fields — they name an identity on
// the SENDING instance that means nothing here — and a flow with no owner
// cannot dispatch.
$flow->setEnabled(false);
$flow->setOwner(null);
$flow->setOrganisation(null);

The reasoning is sound and the safety goal is right. The implementation is not, because FlowMapper scopes every read with an equality predicate:

$qb->andWhere($qb->expr()->eq('organisation', $qb->createNamedParameter($organisation)));

NULL = 'anything' is never true in SQL. So an ownerless flow is excluded from flow#index, flow#show, and the run path by construction — and there is no adopt/claim route to set an owner (grep over appinfo/routes.php finds none). flow#update cannot help either: it has to find the row first.

Install is a one-way door. This instance holds 5 such rows, every one permanently unreachable.

The control that makes this airtight

enabled = false is not the filter. 85 rows are disabled and owned, and they list fine. The only difference for the invisible 5 is the NULL owner/organisation.

Why the fix is not "stop nulling the owner"

enabled = false already delivers the property the comment is defending — a bundle cannot arrive and start executing against the receiving tenant's data. The NULL owner adds no safety on top of that; it only adds unreachability.

The narrow fix is to set owner and organisation to the installing user, not to NULL. That keeps the sending instance's identity out (which was the real concern), keeps the flow inert until someone enables it, and leaves it visible to the person who installed it. An adopt endpoint would also work but is a larger surface for the same outcome.

On symptom 2

Unchanged and still verified with a control: a table-backed flow bundles to 1, a register-authored flow bundles to 0, same request otherwise.

Note

I published the first cause without checking the database — the API's three 404s were consistent with "no row" and I stopped there. Three independent read paths agreeing meant only that they share a scoping predicate.

[rubenvdlinde]

Symptom 2 is broader than federation — the SCHEDULER cannot see register-authored flows either

The bundler was the first place I hit this. It is not the only one.

Control, run on a live instance. The same flow definition, byte for byte, posted to each store, then one FlowScheduleWorker tick:

POST /api/flows                    (openregister_flows table)  → 1 run queued  ✅
POST /api/objects/18/184           (the `flows` register)      → 0 runs        ❌

FlowScheduleService::fireDueFlows() resolves candidates from FlowLocator::scheduledFlows(), which reads the table. A schedule authored in the register never fires. There is no error, no refusal, no status message — the run history is simply empty, which reads as a broken scheduler rather than as a flow the scheduler never saw.

Why this matters more than the bundler case

lib/Settings/flow_register.json describes that register, in its own words, as:

the store the resolver reads by default — so triggers, sub-flows and the /test endpoint all work with a flow authored here

That is not true today. The descriptor documents the register as a first-class home for a flow, and at least two subsystems cannot see it:

subsystem	reads	sees register-authored flows
FlowShareableConfigType (bundle)	FlowMapper	✗
FlowScheduleService (cron)	FlowLocator::scheduledFlows()	✗

I have not audited the rest — sub-flows and /test are named in that same sentence and are worth checking before anyone relies on them.

How it stayed hidden

flow-schedule.spec.ts has authored its fixtures into the register since it was written. It could not fail, because it could not run: its beforeAll resolved a flows register that had never been seeded on any instance (#2903), so the whole file errored before reaching an assertion. Fixing the seeding is what made the file execute — and it immediately reported 0 runs.

So the spec that would have caught this was, for its entire life, dead for an unrelated reason.

What I changed, and what I did not

The spec now authors through /api/flows, because that spec is about the scheduler and should use the store the scheduler reads. It passes 2/2, twice.

The product defect is untouched. Either the register becomes a real flow store for these paths, or flow_register.json stops claiming it is one — that is a design call, not a test fix, and papering over it in the fixture would have buried the second instance of this exactly as the first was buried.