Prod build collections cache can be modified

[SStembridge]

Astro Info

Astro                    v4.5.16
Node                     v20.9.0
System                   Windows (x64)
Package Manager          npm
Output                   static
Adapter                  none
Integrations             none

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

When building for production, the first time a collection is loaded it can be manipulated in a way that affects the cache and results in the manipulations carrying over to subsequent calls to getCollection. This doesn't happen when running or building dev.

What's the expected result?

The cached collection should not be affected by operations performed after loading it.
I believe I found the cause is simply line 113 here returning the original array rather than a copy like it does when the cache is used on line 81:

astro/packages/astro/src/content/runtime.ts

Lines 79 to 114 in 8214bac

	if (!import.meta.env?.DEV && cacheEntriesByCollection.has(collection)) {
	// Always return a new instance so consumers can safely mutate it
	entries = [...cacheEntriesByCollection.get(collection)!];
	} else {
	entries = await Promise.all(
	lazyImports.map(async (lazyImport) => {
	const entry = await lazyImport();
	return type === 'content'
	? {
	id: entry.id,
	slug: entry.slug,
	body: entry.body,
	collection: entry.collection,
	data: entry.data,
	async render() {
	return render({
	collection: entry.collection,
	id: entry.id,
	renderEntryImport: await getRenderEntryImport(collection, entry.slug),
	});
	},
	}
	: {
	id: entry.id,
	collection: entry.collection,
	data: entry.data,
	};
	})
	);
	cacheEntriesByCollection.set(collection, entries);
	}
	if (typeof filter === 'function') {
	return entries.filter(filter);
	} else {
	return entries;
	}

Link to Minimal Reproducible Example

https://github.com/SStembridge/astro-collections-cache-prod-build

Participation

• I am willing to submit a pull request for this issue.

[matthewp]

@ascorbic after thinking about it, I think you are probably right that freezing would be a breaking change for people. So it might be better for now that we just make a copy each time getCollection is called and in 5.0 we can switch to freezing.