I'm getting an `Internal Server Error` from an API...
# gooddata-cloud
l
I'm getting an
Internal Server Error
from an API call to GD:
Copy code
"timestamp": "2023-12-06T20:30:23.418+00:00",
      "path": "/api/v1/actions/workspaces/[workspace-id]/execution/afm/execute/result/eaab2cd07d06d325cc7e3922de2079e4c863298f",
      "status": 500,
      "error": "Internal Server Error",
      "requestId": "516554fb-333746"
How can I figure out what the issue is on the GD platform?
i
Hi Levi, I agree that error message doesn’t provide us much information, we will try improve the logging on our end. Could you kindly try to reload your cached data as instructed here to fix the issue, please?
l
I can give that a try. Is there any information you'd need to gather that will be lost when I do that? Can you use that requestId to track down a more detail message?
It seems to indicate Tiger Backend. Its only happening in one of the many "child workspaces" I am able to view that workspace on the GD Platform
🙌 1
Admittedly, I have not done a deep dive on that error yet.
i
That’s very considerate of you, thanks a lot! The resultId that you shared with us in you initial post was actually sufficient info, as per I was able to track down related TraceId and error as well.
l
Excellent. Since it may contain sensitive data, could you message me directly with the information you've found?
i
Honestly, the error message id generic and doesn’t contain any sensitive information(I can try to deep-dive into the LOG and share more details with you via DM, if needed). It simply indicates the Cache was failing, while listing some objects used by this Insight/Visualization object.
l
More and more is pointing to something on our side as the root cause
The path I was following on our end was a dead end. Red Herring, what I thought was causing an issue on our side was really just an issue with my local debugging. I'm in for trying to better understand the error via DM. I will flush the Cache as well
Clearing the Cache resulted in the dashboard loading as expected. So crisis resolved. I'm still hoping you can provide some more information about the context of the error as it relates to the Cache and maybe those Insight/Visualization objects
🙌 1
i
Just copy-pasting the last comment from our private conversation here as well, in case somebody else experiences a similar issue: Have you automated the cache invalidation on your end, please? If no, the issue/error might be simply caused by a fact that new data was uploaded to your database and therefore the cache needed to be refreshed.
👍 1
j
Hi Levi, I just wanted to let you know that the error you posted is caused by some race condition in our caching mechanism. Currently we have an internal ticket open for an investigation and a fix. As you discussed with Ivana, deleting caches helps to fix the situation as a workaround
🙌 1
👍 1
l
Wonderful, thanks for the update. When that issue gets fixed, will it be posted somewhere? Once its fixed I can remove it from my things to account for when I run into issues
i
Hey Levi, Unfortunately, we don’t have any ETA yet, but usually we apply similar fixes during the release and you can track those by following our Release Notes.
j
@Ivana Gasparekova/@Jan Kos thank you for helping Levi and now I’m hoping you can help me a bit. Levi and I (we work together) are continuing to see the cache errors. We’ve increased the frequency of our cache clearing API calls but we are still seeing this problem with some regularity. I’m hoping you could give me some greater insight into if/when a resolution to this issue will be delivered. I looked at the latest release notes, but I see no notes about bugs fixed.
j
Hi Joey, let me check with our engineers and I’ll get back to you.
j
Thank you!
j
Hi Joey, I’m sorry for the silence, unfortunately we don’t have any specific timeline for the fix yet. However, I’ve checked our logs and for the last 14 days I’ve seen the error hit for your organizations only 5 times. Do you have a different experience? Are there any recent failures in insights calculations? If you could provide more details (especially trace ID) I can check the logs if its the same issue or if there is something different going on.
j
I appreciate you getting back to me. I can’t speak directly to the frequency of occurrence for this issue. As we begin to roll this functionality out to our customers, we want very much to avoid the need for the customer to call in a support ticket so that we know to clear the cache. Perhaps you can help me with a different perspective on this topic. Would it be significantly impactful if we were do to more frequent cache clearing operations (in an effort to avoid this scenario)? I realize that it will mean that some rendering will be slower (if GoodData cannot leverage cache data and has to access our data source) but is that the only cost?
j
Hi Joey, I completely understand. For the more frequent cache invalidation - as you mentioned, I don’t see any other “issues” other than the GD would need to query datasource more often to get the data results instead of taking it from caches.
j
Thank you @Jan Kos. I’m going to try to increase the frequency when we invalidate the cache.