Links to other request are broken after Insomnia Update

[morganleroi]

Expected Behavior

I expect, after importing my collection (Exported in Insomnia V4 format), to correctly retrieve all my tags (link to another request payload).

Actual Behavior

I have exported a request collection (Insomnia V4 format) few weeks ago. Import worked well so far (Requests, Env, Tags, ...).

After the update this week (I have the last release). When I import my collection, all my tag (link to another request payload) are broken

You can see on screenshot below that Request dropdownlist is no more selected.

Reproduction Steps

-Create

• Import
• From URL
• Scan

All request and env are correctly imported, but all tags are broken (red).

Is there an existing issue for this?

• I have searched the issue tracker for this problem.

Additional Information

No response

Insomnia Version

2023.3.0

What operating system are you using?

macOS

Operating System Version

macOS Ventura 13.2.1

Installation method

download from Insomia, then auto update

Last Known Working Insomnia version

2023.2.2

[jackkav]

Thanks for the report, we're looking at this.
In the meantime you can workaround it by reselecting the intended request in the dropdown

[morganleroi]

thanks for the reply. Indeed I can re-select but we have huge collections of Insomnia request and it will not be a tiny task to reassign them all :-D

[oliverreid]

Any updates on this? Is the best solution to downgrade to 2023.2.2 until a fix is out? Like @morganleroi we have a large number of links that are not clear/easy to manually update.

[morganleroi]

Same here, people started to stop using Insomnia and our request collections. I convince them to switch from Postman to Insomnia but now they wanna move again :(

[morganleroi]

@jackkav any ETA on this one ? Do you need more repro case ?

[jackkav]

We can't commit to any fix on this at this time as request id collision and resolution is a tricky issue alongside our other sharing features. This is why we assign all new ids when importing nowadays. However we are working to make team sync and git sync ux effective for your use case. Perhaps you can describe where it falls short and help us out.

[morganleroi]

thanks @jackkav . So If I understand correctly, our current setup (Sharing collection in an exported json file) will not work anymore ? If ids are re-assigned, how can we keep track of links between requests ?

[an-nguyen-codeleap]

@morganleroi I faced the same issue. I have to switch to Git Sync in order to share my collections. Git Sync does not work as expected when use inside another existing project. In the end, I have to create a new git branch to use with Git Sync and only some person can push into it to minimize the conflict. I hope it could help.

[mehr-licht]

I face a similar issue.
I export collections with tags containing links to requests.
When importing elsewhere, the link is broken because the requests are recreated with new(different) id.
Why not referencing by name?

[tgruenen]

I have the same trouble. So I think to use names make sense. But then you come in trouble when you rename request. You have to rename the links too! You need a unique ID like an hash of the name+ creation_time_stamp. I think, then you have no collusion any more! How you generate this ID's today. I did not had a look in to the sources yet!

[kap199297]

Is there any update on this issue? This issue is making it impossible to share/import collections. It makes hard to convince other dev saying I can export collection but other can't import it.

[brvaland]

Do we have any update reference to fixing this issue?

[RealLoio]

bump, thinking of switching entire org back to postman

[ravanscafi]

+1

The request ID is already shared in the exported file. It just need to be respected/used instead of generating a new ID when a request is imported and everything should work out of the box.

[baluvanan]

+1
It becomes impossible to use or recommend Insomnia as it stops from sharing the collection.
My case is very similar I have collection which has request payload which is constructed from other request's responses.
Could we expect a fix for this issue ? Because it is happening in the import cycle looks like there is no work around too 👎