Skip to content
This repository has been archived by the owner on Jul 19, 2024. It is now read-only.

Collection/Project imports change request Id, breaking request-chaining #103

Open
1 task done
grangerg opened this issue Nov 14, 2023 · 5 comments
Open
1 task done

Comments

@grangerg
Copy link

Expected Behavior

This is a copy of the original bug that came over with the Kong code: Kong/insomnia#5942
It starts out talking about "tags", but in the comments, things change to talking about request-chaning. There's a chance it's fixed in this PR: Kong/insomnia#6521

There's a comment that implies this got fixed over in Kong/insomnia#5983 but the bug still exists in Insomnium 0.2.3-a: https://github.com/ArchGPT/insomnium/releases/tag/core%400.2.3-a .


Import of a collection/project exported in v4 Json or Yaml (from Insomnia or Insomnium) will retain the exported request Ids, like it does all of the other Ids, so request chaining works.

Actual Behavior

The requests in each collection each get a newly generated request Id. Since the request-chaining setups reference the original Id (from the Json/Yaml export file), all of that functionality breaks.

Reproduction Steps

  1. Create a collection with 2 requests, one of which uses request-chaining to pull response data from the other request.
  2. Export it.
  3. Import it into a new Project.
  4. Notice that the request-chaining doesn't work because the request-reference is incorrect.

Is there an existing issue for this?

Additional Information

No response

Insomnium Version

0.2.3-a

What operating system are you using?

macOS

Operating System Version

Ventura 13.6.2 (22G320)

Installation method

The .dmg download file

Last Known Working Insomnium version

none

@archywillhe
Copy link
Member

archywillhe commented Nov 14, 2023

hi Granger; good catch!; I'm releasing a major release soon (which will make everything file-system-centric) and I will include the fix in the new version

@francbohuslav
Copy link

Perfect. This is most important issue for everyone who wants own synchonizer/exporter. Preserving original IDs during import (or other solution) causes that exported file will be same as imported. Current behaviour duplicates workspace or requests (depend of import type) so it is useless.

@Totalus
Copy link

Totalus commented Dec 21, 2023

@archywillhe Any ETA for this new major release ?

@archywillhe
Copy link
Member

@Totalus Will be somewhere in feb; sorry for the delay - there're more things to fix than expected (and then suddenly I got too hectic with my other work in the recent months)

@marex333
Copy link

marex333 commented Mar 1, 2024

Hi!
Any new ETA for this fix? I'm not rushing, but rather asking for info. Thanks :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants