Error calling GetProject: {"detail":"Not found"}

This was working fine until I internalized the text component (I replugged it to the Pollinate component but it still doesn’t work):

But I can find it online:


This happened after I updated to the latest Pollination plug-in. I restarted Rhino and replaced all the components just in case.

Try login in again. That works for me usually.

1 Like

Hi @Max, what version of the GH plugin are you using for this study? You should get a much better error message in the latest version.

cc: @mingbo

This is error message is not showing an authentication issue, the new version only checks error code 403 for “Not Authorized” issue. In this case, I guess @tyler or @antoinedao could check if this “Not found” error is really because of authentication issue. If yes, our backend needs to change the error code and message for this.

I can’t find the exact trace for the failed request. I see a lot of successful calls from the C# API for Max around this time for this project, though.

I do see that the string aurecon/Geospatial/e6ab2dff-a7ff-495b-a3a8-6221be9b4151

is not the API path that would point to this resource which is


though, that could be an implementation detail of the C# API.

Returning a 404 is a standard practice in REST APIs for when a resource exists but the user-agent has no role related to the resource in question.

GitHub does this, for example, with private repositories. If anyone who is not me tries to visit

You will see a 404 page because I have made that repo private.

In this case, Max’s project is also private (though, everyone on disourse knows about it now :scream_cat: ) so, if the requestor doesn’t have access to it, we return a 404. If someone on Max’s team were to try to edit the project, but they only have read access, then they would see a 403 as they have a role related to the resource, but are not authorized to make changes.

This is to prevent leaking the knowledge of the existence of a resource by someone making API calls to resource IDs that they think might exist but are not authorized to read. Returning a 403 would admit to the existence of the resource where a 404 is ambiguous.

It seems logging in again as @ayezioro suggested was the solution though!

Thanks @tyler for explaining.

Now I know what this error message 404 “Not found” truly means. It is not “Not found of the project”, it is “Not found of this page” even there is no such page concept here. So it could be user’s role issue, not really only the expired account’s authentication problem.

And also I now understand 403 “Not authorized” is not only for not authenticated for login, but also for user role’s checking.

I guess I will need to catch a different error code for expired authentication issue. Could you tell me what the correct logic is to check the errors for users only because of their login session has been expired?

1 Like

If the session is expired, it could be 200, 403, or 404, depending on the resource they are trying to access (assuming it exists). In the case that a request has no authentication at all, the request is assigned the user anonymous who has no roles for any resource.

However, public resources can be seen by anyone. E.g. if you were to visit
from a private window, you can still get info on ladybug-tools.

How does GH handle the JWT? The client should be able to refresh it without prompting the user for a login.

@mingbo, just in case you you missed it, you can see all the possible responses for each call and the reason behind it here: pollination-server - ReDoc

I am using Colibri to export out all design runs to design explorer and every time I iterate through each simulation completely, I have to un-login/re-login, otherwise I get this error

@compdesignernz what do you mean by “iterate through each simulation completely”?

I’ve been having the issue where, while I’m using Colibri to pull the runs one at a time, at some point Pollination logs out. My workaround is to re-log in and set Colibri to “run the rest and append” but it’s a bit of a nuisance.

Is there a way to prevent the pollination session from ending?

1 Like

@Max. Yes, that is the issue. I can run through all the runs in a sim, but pollination logs out :confused:
Next time I’ll give the “run the rest and append”, but if there is a better fix I am all ears!

We use a 3rd party auth system which sets the token lifetime to 1 hour. Is this about the time that it takes to experience this issue? If so, I think we can prevent this on the client side by forcing a refresh before it expires.

1 Like

@mingbo, what’s your take on this issue?

@tyler I could have sworn it was often much shorter than that but will keep an eye out for it in future


@tyler I am finding this to be the appx time, yes. If it’s possible to either trigger a refresh at an hour or have the third party change the token lifetime, that would be fantastic. I believe that @Max and I are finding the issue to be when we are iterating through runs using colibri, and the check runs component loses connection, causing the end of the runs cycle to lose the data. This can be partially resolved by using the “run rest and append to end” option in the colibri aggregator, but it’s a bit niggly, and it would be preferred it we didn’t have to do this :cry:

Hi @tyler is it possible to make the token’s lifetime to 4 or 8 hours for SDK?

I moved this to an internal discussion because we have some design decisions to make to resolve the issue. But, we are working on it and will let everyone know when we have a solution!


Update on this:
We had a call last week to decide on a direction with @mingbo and @antoinedao and decided to change which service the .NET (Rhino, Grasshopper, Revit) clients interact with to authenticate which will allow us to automatically refresh the tokens in the background. This way, we don’t need long-lived tokens to have indefinitely long user sessions.

I’ll be starting on it this week!


Another update:
I finished the changes to the backend and the C# client to fix this. We were able to build on top of the existing token refresh system that we get through our auth provider, but it required changing which backend service we authenticate through, so it took a bit longer.

We’re testing internally now and will release the fix when we’re confident that the change won’t interrupt anyone’s usage of the C#-based clients.