Datatoolbox: Error while upgrading dump

Help
1

Enonic version: 8.0.4

OS: Linux

Hi,

I’m checking the upgrade process and stumbled on a problem when trying to upgrade the server dump, generated in 7.16.4. I got the following exception:

2026-09-16 13:38:44,513 ERROR s.r.enonic.datatoolbox.RcdScriptBean - Error while upgrading dump
java.lang.IllegalArgumentException: RepositoryId must not be longer than 63 characters
        at com.enonic.xp.core.internal.NameValidator.validate(NameValidator.java:113)
        at com.enonic.xp.core.internal.NameValidator.validate(NameValidator.java:131)
        at com.enonic.xp.repository.RepositoryId.from(RepositoryId.java:59)
        at com.enonic.xp.repo.impl.dump.serializer.json.RepoDumpResultJson.fromJson(RepoDumpResultJson.java:62)
        at com.enonic.xp.repo.impl.dump.serializer.json.DumpMetaJson.lambda$fromJson$0(DumpMetaJson.java:70)
        at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:987)
        at com.enonic.xp.repo.impl.dump.serializer.json.DumpMetaJson.fromJson(DumpMetaJson.java:70)
        at com.enonic.xp.repo.impl.dump.serializer.json.DumpMetaJsonSerializer.toDumpMeta(DumpMetaJsonSerializer.java:33)
        at com.enonic.xp.repo.impl.dump.reader.ZipDumpReaderModel8.getDumpMeta(ZipDumpReaderModel8.java:158)
        at com.enonic.xp.repo.impl.dump.upgrade.DumpUpgraderRunner.upgrade(DumpUpgraderRunner.java:35)
        at com.enonic.xp.repo.impl.dump.DumpServiceImpl.upgrade(DumpServiceImpl.java:200)
        at systems.rcd.enonic.datatoolbox.RcdDumpScriptBean.lambda$upgrade$0(RcdDumpScriptBean.java:438)
        at systems.rcd.enonic.datatoolbox.RcdScriptBean.runSafely(RcdScriptBean.java:44)
        at systems.rcd.enonic.datatoolbox.RcdScriptBean.runSafely(RcdScriptBean.java:37)
        at systems.rcd.enonic.datatoolbox.RcdDumpScriptBean.upgrade(RcdDumpScriptBean.java:429)
        at org.openjdk.nashorn.scripts/org.openjdk.nashorn.internal.scripts.Script$Recompilation$1032$360A$dump_upgrade.L:1#post#func(systems.rcd.enonic.datatoolbox:/services/dump-upgrade/dump-upgrade.js:11)
        at org.openjdk.nashorn.javaadapters.java_util_function_Function.apply(Unknown Source)
        at com.enonic.xp.lib.task.TaskWrapper.runTask(TaskWrapper.java:38)
        at com.enonic.xp.task.TaskProgressReporterContext.lambda$withContext$0(TaskProgressReporterContext.java:32)
        at com.enonic.xp.lib.task.TaskWrapper.run(TaskWrapper.java:31)
        at com.enonic.xp.impl.task.DescribedTaskImpl.run(DescribedTaskImpl.java:58)
        at com.enonic.xp.impl.task.TaskRunnable.lambda$doRun$0(TaskRunnable.java:56)
        at com.enonic.xp.context.ContextImpl.runWith(ContextImpl.java:88)
        at com.enonic.xp.impl.task.TaskRunnable.doRun(TaskRunnable.java:56)
        at com.enonic.xp.trace.Tracer.trace(Tracer.java:147)
        at com.enonic.xp.impl.task.TaskRunnable.run(TaskRunnable.java:39)
        at java.base/java.util.concurrent.ThreadPerTaskExecutor$TaskRunner.run(ThreadPerTaskExecutor.java:291)
        at java.base/java.lang.VirtualThread.run(VirtualThread.java:460)

I see we indeed have some repos whose name is over 63 chars (Explorer repos).

Is there any suggestion on what to do?

2

It’s a flaw in the Explorer app that it allows creating repositories with such long names. Although I’m not sure why even give repos names longer than 63 characters - they are names, not descriptions.

In any case, the only solution you have for this is to create a script which will create new repositories with valid short names, then move child nodes from the old repository with long name to the new one with short name.

Then try dump again.

3

Basically - I ACK Alan’s answer.

Repositories with long names must me manually migrated and the best feature for that - node export and import.

As for Explorer repositories we will look into migration strategy when we prepare XP 8 compatible Explorer.

4

The migration feat would be appreciated, as we have a lot of collections there, in three (cloud) servers. Locally it’s fine to deal with it (I just discarded the longer ones), but now I just realized the issue goes into node.connect as well. With the current naming, we have 28 chars left for collection naming (starting off com.enonic.app.explorer.collection.), affecting 50% of our collections.