ArchGPT / insomnium

Insomnium is a fast local API testing tool that is privacy-focused and 100% local. For testing GraphQL, REST, WebSockets and gRPC. This is a fork of Kong/insomnia
MIT License
3.33k stars 125 forks source link

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

Open grangerg opened 8 months ago

grangerg commented 8 months ago

Expected Behavior

This is a copy of the original bug that came over with the Kong code: https://github.com/Kong/insomnia/issues/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: https://github.com/Kong/insomnia/pull/6521

There's a comment that implies this got fixed over in https://github.com/Kong/insomnia/pull/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 commented 8 months ago

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 commented 7 months ago

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 commented 6 months ago

@archywillhe Any ETA for this new major release ?

archywillhe commented 5 months ago

@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 commented 4 months ago

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