RocketChat/Rocket.Chat · warning

This instance could not remove the ${item.info.name} app pac

Error message

This instance could not remove the ${item.info.name} app package. If you are running Rocket.Chat in a cluster with multiple instances, possibly other instance removed the package. If this is not the case, it is possible that the file in the database got renamed or removed manually.

What it means

The GridFS-backed app package storage failed to delete an app's package file, and the MongoDB error contained 'File not found for id' — the stored file for the app no longer exists. In a multi-instance cluster the usual cause is another instance winning the delete race during an uninstall/update; otherwise the file was manually renamed or removed from the database. The instance only warns and returns, so app-record removal continues without the file.

Source

Thrown at apps/meteor/ee/server/apps/storage/AppGridFSSourceStorage.ts:65

					resolve(this.idToPath(writeStream.id));
					// An error in the following line would not cause the update process to fail
					// eslint-disable-next-line @typescript-eslint/no-empty-function
					this.remove(item).catch(() => {});
				})

				.on('error', (error: any) => reject(error));

			writeStream.write(zip);
			writeStream.end();
		});
	}

	public async remove(item: IAppStorageItem): Promise<void> {
		try {
			await this.bucket.delete(this.itemToObjectId(item));
		} catch (error: any) {
			if (error.message.includes('File not found for id')) {
				console.warn(
					`This instance could not remove the ${item.info.name} app package. If you are running Rocket.Chat in a cluster with multiple instances, possibly other instance removed the package. If this is not the case, it is possible that the file in the database got renamed or removed manually.`,
				);
				return;
			}
			throw error;
		}
	}

	private itemToFilename(item: IAppStorageItem): string {
		return `${item.info.nameSlug}-${item.info.version}.package`;
	}

	private idToPath(id: NpmModuleMongodb.GridFSBucketWriteStream['id']): string {
		return this.pathPrefix + id;
	}

	private itemToObjectId(item: IAppStorageItem): ObjectId {
		return new ObjectId(item.sourcePath?.substring(this.pathPrefix.length));

View on GitHub (pinned to b2c16d5842)

Solutions

  1. In a cluster this is expected and harmless — confirm only one instance was processing the uninstall and ignore
  2. Single instance: query GridFS (fs.files) for the '<nameSlug>-<version>.package' file to see if it was renamed or removed manually
  3. If records are inconsistent, reinstall the app and uninstall it again to reconcile app record and stored package
Defensive patterns

Strategy: validation

Validate before calling

// check the GridFS file exists before deleting, making the race explicit
const [file] = await bucket.find({ _id: itemToObjectId(item) }, { limit: 1 }).toArray();
if (!file) {
	// already removed by another instance or manually — nothing to do
	return;
}
await bucket.delete(itemToObjectId(item));

Try / catch

try {
	await bucket.delete(id);
} catch (error: any) {
	if (/File not found for id/.test(String(error?.message))) return; // benign race
	throw error;
}

Prevention

When it happens

Trigger: Uninstalling or updating the same app on two Rocket.Chat instances at the same moment; a previous uninstall deleted the GridFS file but died before cleaning the app record; manual deletion/rename of documents in the fs.files/fs.chunks (Uploads/GridFS) collections leaving the app storage item pointing at a stale file id.

Common situations: Cluster deployments where app operations land on different nodes; partial uninstalls after crashes or disk-full errors; admins doing manual database surgery on upload collections.

Related errors


AI-assisted analysis of RocketChat/Rocket.Chat@b2c16d5842 (2026-08-18). Data as JSON: /api/errors/d0c747d8eb1f7fa7. Report an issue: GitHub.