workflowengine: File entity reuses the node of the first "Tag assigned" event for all later events in the same process

从 OCA\WorkflowEngine\Entity\File 类开始，其中 getNode() 将解析出的节点缓存到 $this->node，而 prepareRuleMatcher() 在设置新事件时不会清除该缓存。分别在关闭和开启重置标志的情况下运行 issue 中的只读复现脚本，确认同一进程中两个 "Tag assigned" 事件会评估同一个节点。完成标准是每个事件都能解析各自的文件，并且有测试覆盖同一进程中的两个分配事件；FileSystemTags 的缓存是另一个尚未验证的问题。

⚠️ This issue respects the following points: ⚠️

• This is not a troubleshooting question, general support matter, or webserver/proxy problem, but likely a bug.
• This issue is not already reported on Github OR solved at the Community Help Forum (I've searched!).
• I'm using a maintained major version of Nextcloud Server and tested against the latest patch level. (Reproduced on 34.0.3; the affected files are byte-identical in 34.0.6 and unchanged apart from formatting in 35.0.3 and master.)
• I agree to follow Nextcloud's Code of Conduct.
• I've tried my best to provide clear reproduction steps that someone unfamiliar with this bug could use to reproduce it.

Bug description

OCA\WorkflowEngine\Entity\File is resolved from the DI container and is therefore a per-process singleton. For MapperEvent::EVENT_ASSIGN ("Tag assigned"), File::getNode() stores the resolved node in $this->node:

protected function getNode(): Node {
    if ($this->node) {
        return $this->node;
    }
    ...
    case MapperEvent::EVENT_ASSIGN:
        ...
        $this->node = $this->root->getFirstNodeById((int)$this->event->getObjectId());

prepareRuleMatcher() sets the new $event/$eventName, but it never resets $this->node. Every later "Tag assigned" event in the same PHP process is therefore matched against the file from the first event: setEntitySubject() and setFileInfo() both use the stale node.

Web requests usually handle only one tag assignment, so the problem stays hidden there. Long-running processes such as cron.php handle many assignments in a row (CronService runs jobs for up to 14 minutes), and there it does real damage. A common setup is affected directly:

• files_automatedtagging assigns tags in a background job (AssignTagsJob).
• A second flow reacts to "Tag assigned" with a "File has tag" check.

Depending on which file comes first in a cron run, the second flow then either does not run for any later file in that run, or runs for files it should not match.

On our instance, a bulk upload of about 7,600 PDFs led to the following:

• 2,461 files received the tag from files_automatedtagging, but the OCR flow (workflow_ocr, triggered by "Tag assigned") never created a job for them.
• 695 files were processed two to four times.

Steps to reproduce

1. Flow A (files_automatedtagging): "File updated", MIME type PDF and not tag X → assign tag X. The tag is assigned by AssignTagsJob in cron.
2. Flow B: any operation on "Tag assigned" with "MIME type PDF and file has tag X". We use workflow_ocr. When it finishes, it removes X and adds tag Y.
3. Upload many PDFs, so that several AssignTagsJobs and flow B jobs end up in the same cron.php run.
4. Some files keep tag X without flow B ever having run for them; others are processed by flow B several times.

Read-only reproduction that does not change tags or queue jobs. Run it as the web server user with php inside the Nextcloud container, with REPRO_ARGS="<reset 0|1> <fileid> <fileid>". Use one file that has tag X and one that does not.

<?php
require_once '/var/www/html/lib/base.php';
\OC_App::loadApps();
use OCP\SystemTag\MapperEvent;
$args = explode(' ', getenv('REPRO_ARGS'));
$reset = $args[0] === '1';
$ev = MapperEvent::EVENT_ASSIGN;
$manager = \OCP\Server::get(\OCA\WorkflowEngine\Manager::class);
$entity = \OCP\Server::get(\OCA\WorkflowEngine\Entity\File::class);
$op = \OCP\Server::get(\OCA\WorkflowOcr\Operation::class); // class of any operation configured for "Tag assigned"
$prop = new ReflectionProperty($entity, 'node');
foreach (array_slice($args, 1) as $fid) {
    if ($reset) { $prop->setValue($entity, null); }
    $event = new MapperEvent($ev, 'files', $fid, [4]);
    $rm = $manager->getRuleMatcher();
    $rm->setEventName($ev); $rm->setEntity($entity); $rm->setOperation($op);
    $entity->prepareRuleMatcher($rm, $ev, $event);
    $match = $rm->getFlows(true);
    echo "event_file=$fid evaluated_node=" . $prop->getValue($entity)->getId() . ' match=' . ($match ? 'yes' : 'no') . "\n";
}

Output with the rule "PDF and has tag X". File 94069 has only tag Y; file 4365 has only tag X.

reset=0 order=94069 4365
event_file=94069 evaluated_node=94069 match=no
event_file=4365  evaluated_node=94069 match=no    <- wrong, 4365 has tag X
reset=1 order=94069 4365
event_file=94069 evaluated_node=94069 match=no
event_file=4365  evaluated_node=4365  match=yes
reset=0 order=4365 94069
event_file=4365  evaluated_node=4365  match=yes
event_file=94069 evaluated_node=4365  match=yes   <- wrong, 94069 does not have tag X
reset=1 order=4365 94069
event_file=4365  evaluated_node=4365  match=yes
event_file=94069 evaluated_node=94069 match=no

Expected behavior

Each "Tag assigned" event is evaluated against the file in that event, regardless of what was evaluated earlier in the same process.

A possible fix is to reset the cached node whenever a new event is prepared, e.g. at the start of File::prepareRuleMatcher():

$this->node = null;

The reproduction above (reset=1) shows that resetting the node fixes both directions.

Nextcloud Server version

34

Operating system

Other

PHP engine version

PHP 8.3

Web server

Other

Database engine version

PostgreSQL

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)

Configuration report

Not relevant for this bug: Nextcloud All-in-One 34.0.3 on Ubuntu 26.04.1 LTS, PHP 8.3.33, PostgreSQL 18.4, AIO web server container, background jobs via cron.

List of activated Apps

Relevant apps: workflowengine 2.16.0, systemtags 1.24.0, files_automatedtagging 5.0.0, workflow_ocr 1.34.1, app_api 34.0.0.

Nextcloud Signing status

No response

Nextcloud Logs

Nothing is logged: the rule simply does not match, or matches wrongly.

Additional info

Possibly related, found by reading the code and not tested: Check\FileSystemTags is also a singleton. It caches tag IDs per file ID ($fileSystemTags) and does not invalidate them when tags change. In a long-running process, a file whose tags changed after an earlier check can therefore still be evaluated with outdated tags.

As a workaround we re-assign the tag per file with occ tag:files:delete/tag:files:add, so each assignment runs in a fresh process.

Disclosure: I used an AI assistant (Claude) to analyse the code, write the read-only reproduction and draft this report. I reviewed and verified the results on my instance.