Forgets all gRPC requests on Protobuf reload

[splix]

Expected Behavior

Insomnia should keep gRPC request definitions even if probuf files were reorganized.

Actual Behavior

Insomnia removes all existing gRPC bodies from workspace if remove ".proto" file definition and restart.

Reproduction Steps

1. Load a .proto file
2. Create a gRPC request
3. Select "Click to change proto file" and remove original file
4. Note that the request is still intact
5. Restart Insomnia
6. It starts with empty bodies for all gRPC requests that were associated with that .proto file

Is there an existing issue for this?

• [X] I have searched the issue tracker for this problem.

Additional Information

I had to remove and add a protobuf definition because Insomnia wasn't able to see changes to gRPC methods. Removing and adding the .proto file helped to fix that and allowed to select a new method for a new request, but at the same time it erased all previous requests.

Insomnia Version

2021.7.1

What operating system are you using?

macOS

Operating System Version

11.6

Installation method

insomnia.rest

Last Known Working Insomnia version

No response

[filfreire]

@splix thank you for reporting this.

I've tried reproducing your steps in Insomnia latest build (2021.7.2) , but I'm not sure what is the problem.

Insomnia will show a warning that it needs the .proto file before we try to remove it, in order to have the requests. The only apparent weird thing I see is that we don't remove the gRPC methods right after removing the the .proto file.

Is your issue related with this:

I had to remove and add a protobuf definition because Insomnia wasn't able to see changes to gRPC methods

where Insomnia is not correctly displaying the updated gRPC methods for all request definitions if you update the .proto file?

(See recording here: https://www.loom.com/share/ce789e3e8aed4107880c6b910f4d1d6b )

[splix]

Yes, I understand the warning, and I understand that the methods would work w/o .proto file.

The issue is that it completely erases them. I expect to keep them untouched. I mean, I understand that I would not be able to execute them, that's fine. But deleting the related request bodies looks like a bug.

Also I expected that if I returned the same .proto file back, it would make the methods work as before. But in practice, it cannot happen because the methods are already erased from the Insomnia workspace.

(maybe I'm not very clear, and I'll try to make few screenshots to show what happens)

[filfreire]

The way I see it, this would be more of an possible improvement than a bug, in the sense that, you'd like as a user to have methods saved in a way so that:

• in case proto file is removed, still keep the request bodies.
• keep some sort of method name information after proto file deletion

I understand that the methods would work w/o .proto file.

This is problematic with Insomnia's current implementation, as it is linked with the proto file entity. You can in theory try to send a request, with what is still visible on the method dropdown, but Insomnia itself is missing method data from the moment you delete proto file, and request fails, example:

Possible solution

One way of solving this would be perhaps splitting "the logic" in such a way that we keep the method name (detached from proto file logic after deletion) and let you run a request the same way folks can run grpcurl (link) without needing a proto file:

grpcurl -d '{"id": 1234, "tags": ["foo","bar"]}' \
    grpc.server.com:443 my.custom.server.Service/Method

cc'ing @wdawson and @develohpanda to get their feedback - I think this might be an interesting improvement where we could reach a middle ground and say... we allow folks to write down custom gRPC method names and request bodies - not requiring any dependency/import with proto files, so we would support our current approach (via import proto file) and also something closer to grpcurl.

[splix]

It's weird, but I cannot reproduce it anymore. Now, instead of deleting the associated request body, it keeps it as is. Expected behavior, basically. And it even shows the list of methods that were previously available.

I guess the application got an upgrade, and it's fixed now. The current version I have is 2021.7.2

[filfreire]

@splix let us know if it's ok to close the issue, thanks in advance about the info on 2021.7.2 👍

[splix]

Yes, I guess it's ok to close. Seems to be fixed already. Thank you

[ghost]

Im having this problem with 2017.2.1

I would think the request body, response, headers and request should be linked to the left hand request object. Whilst the proto is essentially used to provide the encoding, if I update my proto files, Id hope to be able to auto update them. If the request to the service is no longer valid due to a proto change then highlight it in red or just fail when sending the request.

Loosing all my request objects each time I update my proto files is very frustrating.

This is most definately a bug as none of the other functionality in Insomnia is linked to the request "url".

[wdawson]

Im having this problem with 2017.2.1

To confirm, are you able to reproduce this issue on the current version (2021.7.2)?

[dselans]

This is an ongoing issue - happens to me as well - happened just now on 2021.7.2.

There should also be a way to "refresh" your schemas but the only way to do that right now is to remove your protos altogether - but this results in the issue described by op - the request bodies are all removed.

EDIT: I was about to submit a separate issue requesting to have the functionality to "reload" protos. Should I? Our org updates our protos daily so "removing and re-adding a proto dir" is not an option.

[dsaiko]

I also think reloading proto files without losing existing requests is quite an essential need for development of grpc services. Please consider.

[petitout]

Same issue, that's annoying

[brunoluizkatz-NETZSCH]

Same issue here, reseting old request bodies is annoying, always I forget to copy the requests body

[petitout]

For gRPC requests, I now use Kreya (https://kreya.app/) which is amazing

[dselans]

Thank you @petitout!

[brunoluizkatz-NETZSCH]

@petitout thanks a lot

[filfreire]

Hi folks, on latest Insomnia you can now use gRPC reflection and don't need to rely on importing the proto files into insomnia.

[Tomasito665]

Hi @filfreire. How does reflection fix the issue? I tried to set up some gRPC requests using server reflection. After restarting Insomnia, the bodies of all requests are empty as well as the dropdown list of available gRPC methods. As a result, I need to click "Click to use server reflection", re-select the gRPC method, and rebuild the request bodies after every application restart. For me, this issue makes Insomnia effectively unusable for day-to-day gRPC method testing.

[splix]

Just upgraded to 2023.4.0 and it erased the bodies again (no reflection, just plain proto files)