Tags added in bulk do not update post routing

[cathysarisky]

Issue Summary

Adding a tag in bulk does not seem to trigger a recalculation of what collection the the post belongs in. This causing confusing issues for sites with non-default routes.yaml files that use tags for filtering .

Steps to Reproduce

Create two collections. The first one should be filtered by tag.
i.e.

collections:
  /easy/:
    permalink: /easy/{slug}/
    filter: 'tags:[easy]'
  /:
    permalink: /{slug}/
    template: index

Using the list of posts (not the single post editor), bulk assign some posts the 'easy' tag.

Expectation - those posts will appear at /easy/.
Actual - those posts do not appear in the /easy/ collection until they're either individually edited and saved, or until a new copy of routes.yaml is uploaded, or possibly other conditions not yet identified.

The posts do appear in /tag/easy immediately, but it appears that the collection routes aren't getting updated?

Ghost Version

5.109

Node.js Version

all

How did you install Ghost?

several options - doesn't seem to matter?

Database type

MySQL 8

Browser & OS version

No response

Relevant log / error output

Code of Conduct

• I agree to be friendly and polite to people in this repository

[ErisDS]

This is a known issue, whereby bulk edits don't fire internal model events. Those events drive loads of followup actions including updating routing, sitemaps etc.

We need to get this wired up in a sane way because bulk editing can fire a lot of events.

The solution short term is to do a normal edit after a bulk edit... that usually gets everything back in order and is why this isn't causing as many issues as we'd expect rn.

[cathysarisky]

Understood on not wanting to cause a huge server load spike, but the present situation does make the bulk tool a lot less useful. I've basically got to tell clients not to use it if they want their Algolia index to stay sync'd, their routing to work, etc.

The updates wouldn't have to fire /fast/ on bulk events. Could it go into the jobs queue or something? I'd be perfectly happy if things were caught up an hour later.

[ErisDS]

Yeah exactly, it needs to work with a queue, which we didn't have back when the feature was implemented!