You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have an instance of structurizr onpremises 2024.03.03 running in Azure's Kubernetes Service that exhibits unexpected behavior when attempting to create or manipulate a workspace. The container uses a persistent volume/persistent volume claim that points to an Azure SMB File share for persistence.
Expected behavior
Ability to upload, manipulate, and view diagrams within a workspace. Ability to delete workspaces.
Observed behavior
On creating a new workspace, the landing page does not display any of the options for loading diagrams into the workspace and the lower corner displays the message "Error error".
[screenshot 1]
The option to export a json or dsl does nothing when selected, the option to import json opens a file picker but does nothing with the selected file. The inspections page lists three errors for the workspace:
[screenshot 2]
The settings page loads and allows me to manage users and rbac, including making the workspace private, and these changes are correctly reflected. Under API details, the API url is listed as "/api" without the base url defined in the structurizr configuration. The base URL is correctly shown in structurizr's invocation logs.
[screenshot 3]
[screenshot 4]
When attempting to delete a workspace, I get the error "TypeError: Cannot read properties of undefined (reading 'id') and the workspace is not deleted
[screenshot 5]
Upon investigating the underlying azure file storage that is volume mounted into the container, a folder is created for each workspace containing a "workspace-datetime.json", "workspace.json", and "workspace.properties" files, all of which have contents. The file "structurizr.log" in the "logs" folder inside the storage root is updated with new log entries.
[screenshot 6]
I have set the application logging level to "ALL" in log4j2.properties and there does not appear to be any logging corresponding to the error appearing inside the application or any of the failures involving file imports or exports.
Steps to reproduce
Navigate to the affected structurizr instance, log in as an administrative user, and select "New workspace"
I have no budget and there's no rush, please fix this for free
More information
The replyurl is present in the configuration based on some work I'm doing to enable saml separate from this issue. The screenshot containing structurizr invocation lists search as "none" from a previous instance where I disabled it for testing - the behavior persists whether or not search is enabled.
All css and other assets appear to load correctly in the affected instance. I have a local instance of the same container running successfully, with the landing page appearing correctly in a new workspace, the ability to upload workspace json, and the api uri on the settings page including the base url from configuration. I'd be happy to provide further information including sanitized versions of the kubernetes manifests if you feel it'd be helpful.
The text was updated successfully, but these errors were encountered:
I don't use Azure, so I'm not sure that I can provide any assistance. Perhaps worth asking on the Slack group whether anybody is using a similar deployment approach.
Thanks for your prompt response! I'll investigate reaching out to the Slack group.
One of my biggest roadblocks in troubleshooting this issue has been that while the UI of the application shows an error message, there doesn't appear to be corresponding output in the logs at any log level. Do you have any thoughts on instrumenting to catch the failure state, or what might be generating the ui-level error that I could try to run down? I've tried increasing the log verbosity of both the root and springsecurity loggers as well and while I got more output none of it seemed relevant to the issue at hand, unfortunately.
Description
I have an instance of structurizr onpremises 2024.03.03 running in Azure's Kubernetes Service that exhibits unexpected behavior when attempting to create or manipulate a workspace. The container uses a persistent volume/persistent volume claim that points to an Azure SMB File share for persistence.
Expected behavior
Ability to upload, manipulate, and view diagrams within a workspace. Ability to delete workspaces.
Observed behavior
On creating a new workspace, the landing page does not display any of the options for loading diagrams into the workspace and the lower corner displays the message "Error error".
[screenshot 1]
The option to export a json or dsl does nothing when selected, the option to import json opens a file picker but does nothing with the selected file. The inspections page lists three errors for the workspace:
[screenshot 2]
The settings page loads and allows me to manage users and rbac, including making the workspace private, and these changes are correctly reflected. Under API details, the API url is listed as "/api" without the base url defined in the structurizr configuration. The base URL is correctly shown in structurizr's invocation logs.
[screenshot 3]
[screenshot 4]
When attempting to delete a workspace, I get the error "TypeError: Cannot read properties of undefined (reading 'id') and the workspace is not deleted
[screenshot 5]
Upon investigating the underlying azure file storage that is volume mounted into the container, a folder is created for each workspace containing a "workspace-datetime.json", "workspace.json", and "workspace.properties" files, all of which have contents. The file "structurizr.log" in the "logs" folder inside the storage root is updated with new log entries.
[screenshot 6]
I have set the application logging level to "ALL" in log4j2.properties and there does not appear to be any logging corresponding to the error appearing inside the application or any of the failures involving file imports or exports.
Steps to reproduce
Navigate to the affected structurizr instance, log in as an administrative user, and select "New workspace"
Screenshot
1
![image](https://private-user-images.githubusercontent.com/169196314/328648045-38762760-c89f-41e7-9d88-c37bad0c14d6.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwMTg4MzgsIm5iZiI6MTcyNDAxODUzOCwicGF0aCI6Ii8xNjkxOTYzMTQvMzI4NjQ4MDQ1LTM4NzYyNzYwLWM4OWYtNDFlNy05ZDg4LWMzN2JhZDBjMTRkNi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwODE4JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDgxOFQyMjAyMThaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0wNmQ1NGI1MmZkNWJiYjZhNWI5MDYwYWQ4ZDZjZGZmNmFiMzhiYzJiMmRjZjFjMWM0ZjMzYzQ0ZDZlYjRmY2E5JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.p6sI08i7w7uaJWTHETdQ46qMW0DX-M5fF7Q--QT2V_w)
![image](https://private-user-images.githubusercontent.com/169196314/328647809-e319e3cb-7991-4062-a16c-27389acc0c84.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwMTg4MzgsIm5iZiI6MTcyNDAxODUzOCwicGF0aCI6Ii8xNjkxOTYzMTQvMzI4NjQ3ODA5LWUzMTllM2NiLTc5OTEtNDA2Mi1hMTZjLTI3Mzg5YWNjMGM4NC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwODE4JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDgxOFQyMjAyMThaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1lNmQxYWVhYzUwYjgxNzA3ZGQwOTQxNTQxOTcyYzM2M2I1ZWJlNjZiOTU5MzBhNzUxODY0MjA0OTNlYTY4OWNjJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.1eb75aibklInpE30E0P34VBS-7mLyf_P3yJtqutJMrs)
![image](https://private-user-images.githubusercontent.com/169196314/328648249-c6b0290e-0f2b-4a19-b035-c632691a7fff.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwMTg4MzgsIm5iZiI6MTcyNDAxODUzOCwicGF0aCI6Ii8xNjkxOTYzMTQvMzI4NjQ4MjQ5LWM2YjAyOTBlLTBmMmItNGExOS1iMDM1LWM2MzI2OTFhN2ZmZi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwODE4JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDgxOFQyMjAyMThaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0xNzFlNTQxYmJmZDFlMzQxNjVmMGU2NjA4Mjc1MzgzYmVlZDdkNTAyNTkyZDQ2MWMwMDE3YWM3ZjZlODQ1ODMzJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.ypSLmNQMh4_rPY0Msx7EUCLTSOs0aT64XXAih-U7Rnc)
![image](https://private-user-images.githubusercontent.com/169196314/328648903-850e7678-6648-4f16-8c4e-a10ae7594332.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwMTg4MzgsIm5iZiI6MTcyNDAxODUzOCwicGF0aCI6Ii8xNjkxOTYzMTQvMzI4NjQ4OTAzLTg1MGU3Njc4LTY2NDgtNGYxNi04YzRlLWExMGFlNzU5NDMzMi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwODE4JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDgxOFQyMjAyMThaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1jZDE5Mjg3YzMyZGRmM2IwNTNlZGY4NTlkZGRlN2ViN2RlY2VkMWIwZTc5NWUxNWQ1YTk2ZGJmNzJhOTY4ZTk2JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.tz_9_xznDJWMqHz9i-_DNLtKbwXjC5SkWoF61RMw3m4)
![image](https://private-user-images.githubusercontent.com/169196314/328649341-4925b3b0-8e24-41cd-90e8-feb4258b0362.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwMTg4MzgsIm5iZiI6MTcyNDAxODUzOCwicGF0aCI6Ii8xNjkxOTYzMTQvMzI4NjQ5MzQxLTQ5MjViM2IwLThlMjQtNDFjZC05MGU4LWZlYjQyNThiMDM2Mi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwODE4JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDgxOFQyMjAyMThaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0wYzViYjk2YmJlMTNkMmYwN2JlMDU2YTZiOGViMGYxMDgzOWYwMThmMWJiZmQyYWY0ODI4YWM2NjFkNWI2M2JkJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.a0US6o8LiOzg1ulSHr0xvTzwy9y3tFnEdRoOXBzBdWI)
![image](https://private-user-images.githubusercontent.com/169196314/328650001-d03eb309-cc18-473a-b150-23fc1b6be544.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwMTg4MzgsIm5iZiI6MTcyNDAxODUzOCwicGF0aCI6Ii8xNjkxOTYzMTQvMzI4NjUwMDAxLWQwM2ViMzA5LWNjMTgtNDczYS1iMTUwLTIzZmMxYjZiZTU0NC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwODE4JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDgxOFQyMjAyMThaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0wMjUyOGVjNTFkNjE1ZjQ0MzRjNGQxOTU1NzY2MWUwYzRmMzQ5ZDU0NWNiN2YzZTYyNDAxNDIyZjY1ZTVmNjEwJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.I4vheNlscFVnLYTa3lFDzskSM9bLUMYslcDZnDvtvaM)
2
3
4
5
6
Code sample
Configuration
structurizr/onpremises:2024:03:03
Severity
Minor
Priority
I have no budget and there's no rush, please fix this for free
More information
The replyurl is present in the configuration based on some work I'm doing to enable saml separate from this issue. The screenshot containing structurizr invocation lists search as "none" from a previous instance where I disabled it for testing - the behavior persists whether or not search is enabled.
All css and other assets appear to load correctly in the affected instance. I have a local instance of the same container running successfully, with the landing page appearing correctly in a new workspace, the ability to upload workspace json, and the api uri on the settings page including the base url from configuration. I'd be happy to provide further information including sanitized versions of the kubernetes manifests if you feel it'd be helpful.
The text was updated successfully, but these errors were encountered: