Error when using Search

[zewar96]

I have never used search and tried it and this is what it gives me back. Version is 4.10.1

Error while executing text search: TypeError: Cannot read properties of undefined (reading 'forEach') at module.exports (/app-rprt/node_modules/@jsreport/odata-to-sql/lib/query.js:54:28) at Object.query (/app-rprt/node_modules/@jsreport/odata-to-sql/lib/transformer.js:54:14) at Cursor.toArray (/app-rprt/node_modules/@jsreport/sql-store/lib/sqlProvider.js:22:29) at replay (/app-rprt/node_modules/@jsreport/jsreport-core/lib/main/store/collection.js:53:21) at /app-rprt/node_modules/@jsreport/jsreport-core/lib/main/store/collection.js:60:18 at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

[admin]

It works for me in latest as well as in the 4.10.1.

Please share details when it happens.

[zewar96]

I am sure it's either provider or data related that's causing the issue. Here's some more details:

We have approximately: 10,852 Files, 678 Folders

To search, i am just clicking the icon in the upper left and as i type anything i get the error that i pasted in the first comment

Here's the config i am using

{ 
	"store": {
		"provider": "fs"
	},
	"blobStorage": {
		"provider": "fs",
		"dataDirectory": "/app-rprt/mount/efs"
	},
	"express": {
		"inputRequestLimit": "200mb"
	},
	"allowLocalFilesAccess": "true",
	"trustUserCode": "true",
	"workers": {
		"numberOfWorkers": 2
	},
	"reportTimeout": 600000,
	"extensions": {
		"fs-store": {
			"persistence": {
				"provider": "aws-s3"
			},
			"compactionInterval": 300000
		},
		"fs-store-aws-s3-persistence": {
			"accessKeyId": "[redacted]",
			"secretAccessKey": "[redacted]",
			"bucket": "[redacted]",
			"lock": {
				"queueName": "[redacted]"
			}
		},
		"studio": {
			"flushLogsInterval": 300000
		},
		"scheduling": {
			"interval": 300000
		}
	},
}

[admin]

Are you able to email me your workspace export to jan.blaha@jsreport.net?
Or please try to isolate the problem by removing your folders to find out which entity is the cause.

[zewar96]

Unfortunately i can't share it and if i start deleting things it's going to be a pain. The export will be huge for us because we have sample data in here and sometimes that's very large. Here's what Claude told me about the error using the code in Git

Root cause chain:

jsreport-studio/lib/textSearch.js:68 builds a projection ($select) for each entity set by walking every property that has a document definition, including ones nested inside complex types. For nested props it joins the path with a dot — e.g. chrome.headerTemplate, phantom.header, wkHtmlToPdf.footer ([textSearch.js:14](C:\Code\Internal Utilities\jsreport\packages\jsreport-studio\lib\textSearch.js#L14), [textSearch.js:28](C:\Code\Internal Utilities\jsreport\packages\jsreport-studio\lib\textSearch.js#L28)). Any recipe that marks a complex-type field document: {...} (chrome-pdf, phantom-pdf, wkhtmltopdf, docx, components, scripts, data, assets, etc.) produces one of these dotted keys.

That $select object is passed down through collection.find() → the SQL provider → odata-to-sql's query.js.

In [query.js:52-57](C:\Code\Internal Utilities\jsreport\packages\odata-to-sql\lib\query.js#L52-L57):

const columns = getColumns(options.$select, entitySetName, model)
for (const selectKey in options.$select) {
columns[selectKey].forEach((c) => { ... })
}
getColumns (same file, lines 4-35) only ever produces entries keyed by top-level entity-type column names (e.g. chrome), and only when obj[columnName] != null — but the actual $select key is the dotted child path (chrome.headerTemplate), so obj['chrome'] is undefined and getColumns never creates a columns['chrome'] entry at all.

The outer loop then iterates the real $select keys, hits columns['chrome.headerTemplate'] → undefined, and calls .forEach on it → exactly the TypeError: Cannot read properties of undefined (reading 'forEach') you're seeing.
What to check to confirm:

Confirm you're on a SQL-backed store (mssql/oracle/postgres sql-store + odata-to-sql), not fs-store — this bug path only exists there.
Which entity types have document: {...} on a nested complex-type property (not the top-level content/helpers fields, those are fine because their key has no dot). Candidates in this codebase: chrome.headerTemplate/footerTemplate, phantom.header/footer, wkHtmlToPdf.header/footer/cover. If any of those recipes are enabled, that's almost certainly the trigger — the crash happens on the very first search because textSearch.js builds one combined $select for all entity sets up front.
This is a genuine bug in odata-to-sql's getColumns/query.js — it doesn't handle dotted/nested $select keys for complex types at all, only flat top-level ones. Want me to patch query.js's getColumns to correctly resolve dotted paths into their complex-type sub-columns?