Troubleshooting empty HDI if subscribed on Windows#2550
Troubleshooting empty HDI if subscribed on Windows#2550
Conversation
| ``` | ||
| On macOS and Linux, the built-in implementation continues to be used. | ||
|
|
||
| ### Why are tenant HDI containers empty after subscription on Windows? |
There was a problem hiding this comment.
This is only valid for hybrid testing, right?
There was a problem hiding this comment.
yes, in production you usually sibscribe in CF cockpit
There was a problem hiding this comment.
what difference does this make? If you have built your app on windows, then the resources.tgz is missing (or empty), and then nothing gets deployed to the HDI container, no matter how you subscribe.
So I think this applies also to production.
Or am I wrong here?
There was a problem hiding this comment.
What I mean: it doesn't matter how you subscribe, but how the app is built
There was a problem hiding this comment.
@stewsk: Agree, then we should change from "troubleshooting empty HDI" - just copied it from the issue :) - to "issues building MTX resources". And for the last one we already have troubleshooting item above - I will modify it.
There was a problem hiding this comment.
But the visible impact is on the deployed application
There was a problem hiding this comment.
@ecklie: In some cases we obtain an explicite error "tar: Error is not recoverable" by cds build. In some other cases cds build may silently fail, which can be seen only on the deployed application. My question for now: In troubleshooting guide - should it be one or two sections?
There was a problem hiding this comment.
For the error message we do have the troubleshooting info already. So this can be found. How would we describe the other case? How would one notice on the deployed application if the build doesn't throw an error?
There was a problem hiding this comment.
How would we describe the other case? How would one notice on the deployed application if the build doesn't throw an error?
This is exactly what the newly added section does: "Why are tenant HDI containers empty after building app on Windows?"
My question was if we should merge those two section?
There was a problem hiding this comment.
ok, two different errors -> two sections
ecklie
left a comment
There was a problem hiding this comment.
Yes, the problem is caused by the build. It also has impact on the productive app. We need to check if we can improve the build and add a consistency check.
| ``` | ||
| On macOS and Linux, the built-in implementation continues to be used. | ||
|
|
||
| ### Why are tenant HDI containers empty after building app on Windows? |
There was a problem hiding this comment.
I might be wrong or simplify it too much, but to me this reads as if there's is already a first analysis done and I found that HDI containers are empty.
What is it that makes me investigate? Like "Can't get/read data from customer tenant"?. So folks who have not done an initial analysis and found the empty containers, what would they look for in our troubleshooting?
There was a problem hiding this comment.
Here the ticket describibg the issue: https://github.tools.sap/cap/issues/issues/19999.
There was a problem hiding this comment.
in my case the "symptom" was that I got funny runtime errors from the Node.js runtime saying that table xyz is not there (don't remember the precise error message)
There was a problem hiding this comment.
Right. It is not after building an app but after subscription.
"Why are tenant HDI containers empty after tenant subscription"
It think the error message is something like "table not found". I will check it.
There was a problem hiding this comment.
SqlError: invalid table name: Could not find table/view ...
There was a problem hiding this comment.
@renejeglinsky: i changed the title. In your suggestion I didn't like "Most likely you're using Windows" - using Windows is rather an exceptional situation. i merged your changes from the suggestion.
There was a problem hiding this comment.
@vkozyura If I understand the issue correctly, Windows is the "most likely" case when someone encounters this error, or? There might be other situations where a similar error occurs, but this is then not OS-specific. Probably. We don't know for sure. And this is what I wanted to express.
| ### Why are tenant HDI containers empty after building app on Windows? | ||
|
|
||
| On Windows, cds build --production may silently fail to create resources.tgz in the MTX sidecar build output. | ||
| The build log will incorrectly report the file as written. | ||
|
|
||
| Install the tar library to fix this: | ||
|
|
||
| ```sh | ||
| npm add -D tar | ||
| ``` | ||
| On macOS and Linux, the built-in implementation continues to be used. | ||
|
|
There was a problem hiding this comment.
I'd also suggest to move this entry to the MTXS section of this guide. WDYT?
| ### Why are tenant HDI containers empty after building app on Windows? | |
| On Windows, cds build --production may silently fail to create resources.tgz in the MTX sidecar build output. | |
| The build log will incorrectly report the file as written. | |
| Install the tar library to fix this: | |
| ```sh | |
| npm add -D tar | |
| ``` | |
| On macOS and Linux, the built-in implementation continues to be used. | |
| ### Why do I get "SqlError: invalid table name" after subscription? | |
| Most likely you're using Windows to build your project. On Windows there's a known issue, where `cds build --production` may silently fail to create the _resources.tgz_ in the MTX sidecar build output. After deployment and subscription, you can then notice the mentioned SqlError or similar error messages that point to tables/views not being available. | |
| :::warning The build log will incorrectly report the file as written. | |
| ::: | |
| To fix this on Windows, install the tar library: | |
| ```sh | |
| npm add -D tar | |
| Even with this dependency added, on macOS and Linux the built-in implementation continues to be used. | |
There was a problem hiding this comment.
The error message I got (cds watch on node RT) was
"Could not find table/view ...... in schema ......:
Co-authored-by: René Jeglinsky <rene.jeglinsky@sap.com>
Co-authored-by: René Jeglinsky <rene.jeglinsky@sap.com>

No description provided.