Dataview query with flatten fails on update to Obsidian 1.03 and Dataview 5.47

What happened?

I have a vault with hundreds of queries exactly as the below - listing tasks in other notes with links to the current file. These worked perfectly well, but now fail on update (of both Obsidian and Dataview). On going into read mode I simply get a pause of about 2 minutes followed by a blank obsidian screen.

I can’t see any reference to a query syntax change that would have broken this, and have no idea how to start debugging it.

To Add: a) I have tried in a completely clean vault with the same plugins and just a single task and a single query file - the query works fine b) Other dataview queries work fine, it is just this specific query that fails always c) It definitely has something to do with the Obsidian/dataview update as that is exact when it stated failing d) I presume it is some sort of cache issue? But what sort of issue would cause only one type of dataview query to fail. Is there some way to clear/reset the cache to check whether that might be a cause, short of copying all 1000 or so notes I have into a clean vault?

DQL

list WITHOUT ID tasks.text + " (" + link(file.link, Title) + ")"
flatten file.tasks as tasks
where contains(tasks.text, "[[" + this.file.name + "]]")
SORT tasks.text ASC

JS

No response

Dataview Version

0.5.47

Obsidian Version

1.03

OS

Windows

[aubreyz]

I tried to reproduce out of curiosity and while it works on the example vault (275 files) and a small set of matching tasks (seven) it takes multiple seconds until the query renders for me. It seems like the performance dropped significantly for this use case, but I do not have any logs in the console. Might I ask how many files your vault has approx - 1000? - and how many results you would except as a rough number?

Yes it may be an extraordinarily slow query - but it used to be fast with exactly the same note dataset (albeit a few extra tasks might have been added).

I have perhaps 1000 notes each containing about 5 tasks on average. A typical query would pull up about 10 tasks at most.

But it is interesting that you are finding a slow render for this particular query even with a tiny dataset - so perhaps it is something that has been magnified by a recent code change?

[aubreyz]

That is an interesting experiment @s-blu which takes the matter much further forward. Given the behavior of dataviewjs and the tasks plugin performing very similar feats with effective flattening (with many items in a few files) I suspect that it must be possible to optimize the flatten code to avoid this roadblock. I’m happy to test things, but the coding is outside of my skill-set 😃

I note your comment about working OK a second time (cache we guess), but at n=2000 or 3000 you don’t get a second chance because it approaches infinity… even at 600 or so it becomes massively problematical.