[Bug]: appsmithctl restore ignores --backup-db-name=<name> and restores from the manifest database name
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- mongodb, typescript
Research direction
Start with getBackupDatabaseName in app/client/packages/rts/src/ctl/restore.ts:415-440 and the failing test described for restore.test.ts. Compare its argument handling with the existing getArgValue usage for --backup-file=, then run the restore suite and RTS TypeScript, ESLint, and Prettier checks. Done means the equals-form override returns legacy-db while the manifest remains the fallback.
Written by the indexing model from the issue text.
Description
Is there an existing issue for this?
- I have searched the existing issues
Description
appsmithctl restore --backup-db-name=<name> ignores the override and restores using the database name from the backup's manifest.json.
getBackupDatabaseName in app/client/packages/rts/src/ctl/restore.ts:415-440 (release @ a6ab36cb26) checks command_args.includes("--backup-db-name"). That only matches an argument that is exactly --backup-db-name. So:
--backup-db-name=legacy-dbnever enters the override branch. The name comes from the manifest ("Backup Database Name: <manifest name>"), andrestoreDatabasepasses that manifest name tomongorestore --nsFrom.--backup-db-name legacy-db(space form) enters the branch, butcommand_args[i].split("=")[1]isundefined. The db name becomesundefined.
As a result, the one flag that exists for restoring a backup taken from a differently named database (#25663, #31004) cannot actually be used. --nsFrom maps from the wrong namespace, and the restore can silently omit the data.
What I expect is that --backup-db-name=<name> overrides the manifest name.
Steps To Reproduce
- Take a backup whose
manifest.jsonhas"dbName": "manifest-db", where the data was actually dumped fromlegacy-db. - Run
appsmithctl restore --backup-db-name=legacy-db. - The log prints
Backup Database Name: manifest-db, andmongorestoreruns with--nsFrom=manifest-db.*.
Failing unit test (red on release, green with the fix):
it("uses --backup-db-name= when remapping a backup to the target database", async () => {
jest.spyOn(fsPromises, "readFile").mockResolvedValue(JSON.stringify({ dbName: "manifest-db" }));
await expect(getBackupDatabaseName("/contents", ["--backup-db-name=legacy-db"])).resolves.toBe("legacy-db");
});
// release: received "manifest-db"
Proposed approach (a fix with a regression test is ready): use the existing getArgValue helper in restore.ts (already used for --backup-file=) to read --backup-db-name=<name>, and keep the manifest fallback. With that change the space form falls back to the manifest name, not undefined. The change is confined to restore.ts. getBackupDatabaseName gains an args parameter that defaults to command_args, so it can be tested. It adds 2 tests in restore.test.ts. The restore suite passes (17/17), along with RTS tsc, ESLint and Prettier.
@contributor-support I'd like to take this. Could it be assigned to me? I'll open the PR against release with Fixes #<this> once it's assigned.
Public Sample App
No response
Environment
Release
Severity
Medium (Frustrating UX)
Issue video log
No response
Version
Self Hosted - release @ a6ab36cb26
Prepared with AI assistance (Claude) from the breken-ai account.
- Dominant language
- TypeScript
- Stars
- 41k
- Forks
- 4.8k
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 66
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from appsmithorg/appsmith
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
appsmithorg/appsmith#42297 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
appsmithorg/appsmith#42296 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
appsmithorg/appsmith#42118 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
appsmithorg/appsmith#42115 · 2 comments ·
Maintainers usually reply within 1 day
-
close-labeler workflow uses break instead of continue, dropping the QA label on multi-issue PRsOpenContributor Expressed Interest
Difficulty 1/5 Under an hour Newbie friendliness 88/100
appsmithorg/appsmith#41983 · 2 comments ·
Maintainers usually reply within 1 day
All issues in appsmithorg/appsmith
Similar issues
-
refactor
Difficulty 2/5 Half a day Newbie friendliness 84/100
Maintainers usually reply within 5 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
OHDSI/Data2Evidence#3450 ·
Maintainers usually reply within 2 days
-
e2e-failure ready-to-code
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
redhat-developer/rhdh-plugin-export-overlays#4011 · 1 comment ·
Maintainers usually reply within 1 day
-
automation missing-model model-sync provider:ofox
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
anomalyco/models.dev#8421 ·
Maintainers usually reply within 1 day
-
SlackAdapter and TelegramAdapter are not assignable to Adapter under exactOptionalPropertyTypesOpen
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day